prominent message on website about "use only on trusted input"?

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

prominent message on website about "use only on trusted input"?

Alexander Leidinger
Hi,

given the recent messages about more attention by security researchers  
to LAME, I suggest we add a prominent message (maybe even on the main  
page) about using LAME only on trusted input.

For me LAME was never developed with security in mind, just to be used  
on trusted input (letting aside the question what trusted input is  
after the rootkit-mistake Sony did in the past).

Comments?

What I propose is something like this (improvements more than welcome):
---snip---
[red]Security notice:[/red] [bold]only use LAME on trusted  
input[/bold], e.g. something you created on your own. LAME was and is  
developed with MP3 encoding / research in mind, not with best seucrity  
principles. Security issues are off course issues which shall be  
fixed, but given the nature of things (e.g. copyright laws (which  
affects what you are legally allowed to feed to LAME) and availability  
of time of the developers of LAME), seucrity is not the number one  
priority.

Note to security researchers: there was never a security review of the  
code of LAME (at least we are not aware of one). As such we would not  
be surprised if it is easy to find security issues. We welcome off  
course responsible security disclosure, but given the available /  
active resources working on LAME, we can not promise timely responses  
/ fixes. As such we will not complain about a reduced "timeout from  
LAME project" in your responsible disclosure process, but ask you to  
provide a way to reproduce the issue (e.g. a small sample input file  
which leads to a segfault, not a full exploit) before publishing  
issues. It may also be a good idea to notify GNU/Linux / *BSD  
distributions which ship binary packages of LAME in advance in case  
they want to create fixes before the issue is published.
---snip---

What do you think?

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on trusted input"?

bouvigne
On 2017-07-28 11:56, Alexander Leidinger wrote:

> given the recent messages about more attention by security researchers
>  to LAME, I suggest we add a prominent message (maybe even on the main
>  page) about using LAME only on trusted input.

Hello,

Did we had reports on inputs not handled through the decoding library?
If all the identified issues are through decoding, it might be worth
explaining that LAME can be built without decoding features, which
reduces the number of identified issues.

Regards,

--
Gabriel Bouvigne

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on trusted input"?

electricworry
In reply to this post by Alexander Leidinger
On 28 July 2017 at 10:56, Alexander Leidinger <[hidden email]> wrote:
> given the recent messages about more attention by security researchers to
> LAME, I suggest we add a prominent message (maybe even on the main page)
> about using LAME only on trusted input.
>
> For me LAME was never developed with security in mind, just to be used on
> trusted input (letting aside the question what trusted input is after the
> rootkit-mistake Sony did in the past).
>
> Comments?

If I may chime in, I would say that the security of LAME seems good.
None of the issues I've seen allow for any remote code execution. At
best they can crash the program (probably getting a CVSS score of
around 2.5) or they only crash the program if caught by address
sanitizer (so a normal build would get a CVSS score of 0.0).

What would you be trying to achieve with such a disclaimer. If it's to
avoid claims of liability, that's understandable but I would imagine
you've already got that in the license already.

If it's to protect the project from the work of having to deal with
reports of security type issues, then I'm not sure that's a great
idea. At some level, the LAME project wants to be used and trusted
widely, and if a project was to ignore security reports, I think
that's a problem for distros and other adopters. I think the best
approach would be to deal with these small issues with the priority
they deserve (low or none). I also think/hope that in the unlikely
event of a higher severity remote code execution that you would want
to resolve that.

Just my two cents...

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on trusted input"?

Thomas Orgis
In reply to this post by bouvigne
Am Fri, 28 Jul 2017 12:31:03 +0200
schrieb [hidden email]:

> Did we had reports on inputs not handled through the decoding library?

Barring any work to finally replace the mpglib, recommending use of
LAME with plain PCM/WAV only might be a sensible option.

Perhaps a quick intermediate step could be to replace the decoder part
of mpglib with libmpg123 bindings and keep the internal mpglib for the
frame analyzer tool? If such a change would be considered, I could be
motivated to prepare the patch. Then we only need a warning to use the
current version, please … denial of service of the analyzer seems less
of a public health issue.


Alrighty then,

Thomas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on trusted input"?

Mp3 - Lame mailing list
Does anybody even use the frame analyzer anymore? It requires gtk1, for crying out  loud!
I agree with bringing the internal decoder up to current mpg123 version and keeping mpglib only for the analyzer
 -- 
Roberto José de AmorimMSc in Computer Science
Columbia University - New York



      De: Thomas Orgis <[hidden email]>
 Para: [hidden email]
 Enviadas: Sexta-feira, 28 de Julho de 2017 9:09
 Assunto: Re: [Lame-dev] prominent message on website about "use only on trusted input"?
   
Am Fri, 28 Jul 2017 12:31:03 +0200
schrieb [hidden email]:

> Did we had reports on inputs not handled through the decoding library?

Barring any work to finally replace the mpglib, recommending use of
LAME with plain PCM/WAV only might be a sensible option.

Perhaps a quick intermediate step could be to replace the decoder part
of mpglib with libmpg123 bindings and keep the internal mpglib for the
frame analyzer tool? If such a change would be considered, I could be
motivated to prepare the patch. Then we only need a warning to use the
current version, please … denial of service of the analyzer seems less
of a public health issue.


Alrighty then,

Thomas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev


   
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on trusted input"?

Alexander Leidinger
In reply to this post by electricworry
Quoting electricworry <[hidden email]> (from Fri, 28 Jul 2017  
12:51:00 +0100):

> On 28 July 2017 at 10:56, Alexander Leidinger  
> <[hidden email]> wrote:
>> given the recent messages about more attention by security researchers to
>> LAME, I suggest we add a prominent message (maybe even on the main page)
>> about using LAME only on trusted input.
>>
>> For me LAME was never developed with security in mind, just to be used on
>> trusted input (letting aside the question what trusted input is after the
>> rootkit-mistake Sony did in the past).
>>
>> Comments?
>
> If I may chime in, I would say that the security of LAME seems good.
> None of the issues I've seen allow for any remote code execution. At
> best they can crash the program (probably getting a CVSS score of
> around 2.5) or they only crash the program if caught by address
> sanitizer (so a normal build would get a CVSS score of 0.0).
>
> What would you be trying to achieve with such a disclaimer. If it's to
> avoid claims of liability, that's understandable but I would imagine
> you've already got that in the license already.
>
> If it's to protect the project from the work of having to deal with
> reports of security type issues, then I'm not sure that's a great
> idea. At some level, the LAME project wants to be used and trusted
> widely, and if a project was to ignore security reports, I think
> that's a problem for distros and other adopters. I think the best
> approach would be to deal with these small issues with the priority
> they deserve (low or none). I also think/hope that in the unlikely
> event of a higher severity remote code execution that you would want
> to resolve that.

The goal is to set the expectations of the users right.

Fact is, the last released version is 5 years old. Some parts of LAME  
can surely be improved, but it didn't really happen. Those people with  
write access to the source of LAME did not really produce some  
enhancements which seem to be worth a new release within 5 years.  
Patches which are available (either in a linux distribution or in the  
bugtracker) are not looked at and committed. I also don't have the  
impression that anyone had a look at the reports of security issues we  
got in the last month (not only from you). I would like to have a look  
at them and to fix them, I just don't have (/make) the time to do it.  
I expect the I'm not the only one in this regard.

Yes, any security issue in LAME may not be remotely exploitable (as we  
don't listen on the network) and as such doesn't get a high CVSS  
score. It will also only be exploitable in the context of the user  
which executes lame with the malicious input file and as such (let'S  
assume nobody runs it as root) is not related to a root-exploit (and  
again doesn't get a high CVSS score). What could happen is a DoS, if  
LAME is used in an automated music conversion service, but then it is  
on those which have setup such a service to protect it from a DoS.  
What also could happen is some kind of ransomware-infection (in the  
worst case), which may not be likely, but something you don't want to  
happen to you.

In the end the CVSS score doesn't matter, what matters is that there  
may be a disclosure of a security issue with no fix from our side (if  
we take the last 5 years as the benchmark of changes in LAME). Even if  
the issue is just a segfault, what is visible is "there is no fix for  
a security issue". We can even go further, we have an encrypted  
archive in the bugtracke. If it is encrypted and not readable for  
everyone, everyone who stumbles over this has to think that it has to  
be a serious issue, right? And it is not looked at or even fixed.

So why not being honest and tell to the people: look, we have a bad  
track record of reacting to reported issues/patches, and we know that  
nobody made sure that LAME is secure. If you use "good" input files,  
everything will be fine, but if you use malicious input files  
(specially crafted files to do harm to wherever the account which  
executes LAME has access to), then we don't know what will happen  
(best case only a segfault), so better make sure you only use "good"  
input files.

Maybe this is exagerated. Maybe it is not necessary. That's why I  
asked for comments.

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on trusted input"?

Mp3 - Lame mailing list

Il 29/07/2017 01:32, Alexander Leidinger ha scritto:
>
> The goal is to set the expectations of the users right.

Well, I think this is a wise starting point.
Look at the sourceforge download stats, they're impressive. Latest lame release is 5 years old, and
still 2500 persons a day get it in source code form. I can figure out everyday user base to be even
larger, given most of the users don't use to build applications from source code, they clic on a
small icon (or type into a console) and expect something happens. Assume they're feeding lame with a
malformed input file: the nice window will suddenly disappear and the text terminal will show a
cryptic death message. I would avoid this to happen, if I could.

Alexander gave us a clear picture of the past of this project, lame development has gradually slowed
down and now seems to be halted. Some sourceforge tickets dates back to 2003, and they still have no
owner! Did anyone read them?
Nevertheless, I see in the latest weeks some messages on this list raised up attention from the dev
team, and most of them chimed in for a contribution. I feel a bit fond of lame (and so do the ones
contributing) and IMHO the warning message proposed by Alexander and user disappointment can be
avoided. If lame project needs some work (indeed it does), then this is the right time for the dev
team to cooperate once again and show the point in lame development. That is, give to all the
"present" picture of the project (something similar to the recent thread about the interaction
between the frame analyzer and the included mpglib, but project-wide). Then, the remaining part
would be answering questions like "what" (fix branch 3.99 ? concentrate effort on new 3.100 ?) and
"how" (stay on cvs ? move to git ?).
BUT, as Thomas (he is a constant source of good ideas) said, the very first question is to define
the "we" here, and I'm willing to help this project.

Elio


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on trusted input"?

bouvigne
In reply to this post by Mp3 - Lame mailing list
On 2017-07-28 14:15, Roberto José de Amorim via Lame-dev wrote:
> Does anybody even use the frame analyzer anymore? It requires gtk1,
> for crying out  loud!
> I agree with bringing the internal decoder up to current mpg123
> version and keeping mpglib only for the analyzer

I've personally found the frame analyser to be very usefull...but my
last contribution was about 10 years ago.

I think that it's very reasonable to assume that only developpers would
use the frame analyser (it's painfull enough to build, so only motivated
people will ge through it :-)). There is absolutely no use of it for a
regular user.
Thus, mpglib for the analyser and mpg123 for "regular" decoding likely
would not cause any "usability" issue.


Regards,

--
Gabriel Bouvigne



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on trusted input"?

Thomas Orgis
Am Sat, 29 Jul 2017 09:56:32 +0200
schrieb [hidden email]:

> I think that it's very reasonable to assume that only developpers would
> use the frame analyser (it's painfull enough to build, so only motivated
> people will ge through it :-)). There is absolutely no use of it for a
> regular user.

It's not that painful. I just had to specify -std=gnu89 for anything
involving gtk+1 (conflicts with glib otherwise). Well, OK, you need to
build gtk+1 as it's not included in binary distros anymore AFAIK, but
that is no issue for me … who cares about binary distros? ;-)

It seems to run just fine, built using GCC 6.3.0 here. And apart from
that … there is not _that_ much GUI involved, as it seems. So porting
to newer Gtk or anything else probably, would be an afternoon walk for
a seasoned GUI programmer, wouldn't it?

> Thus, mpglib for the analyser and mpg123 for "regular" decoding likely
> would not cause any "usability" issue.

Also, the analyser is hooked into the encoder, right? I am starting to
look into the code … could it be that it's using the generic way to get
at PCM input, decoding MP3 along the way, and then hooks mpglib
directly into what lame itself produces? So having the initial decoding
to PCM happen in libmpg123 and only the analyzing stage with mpglib and
its extra hooks would also avoid any danger from malicious input files.
Lame is not producing malicious MP3 data, is it?


Alrighty then,

Thomas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on trusted input"?

bouvigne
On 2017-07-29 11:09, Thomas Orgis wrote:
>
> It seems to run just fine, built using GCC 6.3.0 here. And apart from
> that … there is not _that_ much GUI involved, as it seems. So porting
> to newer Gtk or anything else probably, would be an afternoon walk for
> a seasoned GUI programmer, wouldn't it?

For someone knowledgeable about GTK, it would probably not be long to
adapt.


> Also, the analyser is hooked into the encoder, right? I am starting to
> look into the code … could it be that it's using the generic way to get
> at PCM input, decoding MP3 along the way, and then hooks mpglib
> directly into what lame itself produces? So having the initial decoding
> to PCM happen in libmpg123 and only the analyzing stage with mpglib and
> its extra hooks would also avoid any danger from malicious input files.
> Lame is not producing malicious MP3 data, is it?

Analyser is both hooked into encoder and decoder. MP3X is able to show
MDCT components on an already encoded file, along with some frame
information (bit reservoir, block type,...).
You can see that in the screenshots there:
http://lame.sourceforge.net/screenshots.php

The FhG and MPECKER example are running the analyser over an already
encoded file, without any re-encoding.


--
Gabriel Bouvigne

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on trusted input"?

Alexander Leidinger
In reply to this post by bouvigne

Quoting [hidden email] (from Fri, 28 Jul 2017 12:31:03 +0200):

> On 2017-07-28 11:56, Alexander Leidinger wrote:
>
>> given the recent messages about more attention by security researchers
>> to LAME, I suggest we add a prominent message (maybe even on the main
>> page) about using LAME only on trusted input.
>
> Hello,
>
> Did we had reports on inputs not handled through the decoding library?

Reports on WAV input.

https://sourceforge.net/p/lame/bugs/463/
https://sourceforge.net/p/lame/bugs/462/
https://sourceforge.net/p/lame/bugs/461/

I didn't look at the other reports.
I didn't look closer if it is easy to fix or not (probably there is an  
easy fix to _just_ fix what is reported).

Bye,
Alexander.


--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on

Fabian Greffrath-2
In reply to this post by Alexander Leidinger
Hi there,

Am Samstag, den 29.07.2017, 01:32 +0200 schrieb Alexander Leidinger:

> Fact is, the last released version is 5 years old. Some parts of LAME  
> can surely be improved, but it didn't really happen. Those people with  
> write access to the source of LAME did not really produce some  
> enhancements which seem to be worth a new release within 5 years.  
> Patches which are available (either in a linux distribution or inthe  
> bugtracker) are not looked at and committed. I also don't have the  
> impression that anyone had a look at the reports of security issues we  
> got in the last month (not only from you). I would like to have a look  
> at them and to fix them, I just don't have (/make) the time to do it.  
> I expect the I'm not the only one in this regard.
>

we should also probably ask ourselves how it could ever come this far
and how this stagnancy could get avoided in the future.

I think the main issue is that after the 3.99.5 release the main SVN
branch (trunk) has been (mis-)used a a feature branch for some
improvements to the psycho-acoustic model. However, these improvements
never really took off, the changes were rather considered as
regressions and after the main developer lost time (and/ot interest?),
nobody really dared to touch that code.

Then came the first patches and fixes addressed at the 3.99.5 release
and were applied on top of the current development state, but nobody
dared to do the overdue point release because of all the other changes
to the code [1]. As such, the code wasn't touched at all anymore,
because it couldn't get released as is and no preparations were ever
made to do a point release with minimal changes to the previous one.

This is at least how I perceived what has happened. However, this
doesn't mean that it really was like this.

Anyway, it should be possible to get development back on trail (it
would be easier to organize branches with GIT, but I believe that it is
also somehow possible with the current SVN repo).

I think the following/something similar needs to be done (in GIT
language):

- Create a branch off of the 3.99.5 release
- Make this branch the new "master" branch
- Branch out the changes to the psycho-acoustic model into a dedicated 
  feature branch
- Release 3.99.6

Best regards,

Fabian (I am the Debian Developer co-maintaining the lame package in
Debian and also provided some security-related patches in the past)

[1] https://sourceforge.net/p/lame/mailman/message/34108393/
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on

Fabian Greffrath
In reply to this post by Alexander Leidinger
[Re-sending from the mail address registered at lame-dev]

Hi there,

Am Samstag, den 29.07.2017, 01:32 +0200 schrieb Alexander Leidinger:

> Fact is, the last released version is 5 years old. Some parts of
> LAME  
> can surely be improved, but it didn't really happen. Those people
> with  
> write access to the source of LAME did not really produce some  
> enhancements which seem to be worth a new release within 5 years.  
> Patches which are available (either in a linux distribution or
> inthe  
> bugtracker) are not looked at and committed. I also don't have the  
> impression that anyone had a look at the reports of security issues
> we  
> got in the last month (not only from you). I would like to have a
> look  
> at them and to fix them, I just don't have (/make) the time to do
> it.  
> I expect the I'm not the only one in this regard.
>

we should also probably ask ourselves how it could ever come this far
and how this stagnancy could get avoided in the future.

I think the main issue is that after the 3.99.5 release the main SVN
branch (trunk) has been (mis-)used a a feature branch for some
improvements to the psycho-acoustic model. However, these improvements
never really took off, the changes were rather considered as
regressions and after the main developer lost time (and/ot interest?),
nobody really dared to touch that code.

Then came the first patches and fixes addressed at the 3.99.5 release
and were applied on top of the current development state, but nobody
dared to do the overdue point release because of all the other changes
to the code [1]. As such, the code wasn't touched at all anymore,
because it couldn't get released as is and no preparations were ever
made to do a point release with minimal changes to the previous one.

This is at least how I perceived what has happened. However, this
doesn't mean that it really was like this.

Anyway, it should be possible to get development back on trail (it
would be easier to organize branches with GIT, but I believe that it is
also somehow possible with the current SVN repo).

I think the following/something similar needs to be done (in GIT
language):

- Create a branch off of the 3.99.5 release
- Make this branch the new "master" branch
- Branch out the changes to the psycho-acoustic model into a dedicated 
  feature branch
- Release 3.99.6

Best regards,

Fabian (I am the Debian Developer co-maintaining the lame package in
Debian and also provided some security-related patches in the past)

[1] https://sourceforge.net/p/lame/mailman/message/34108393/
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on

bouvigne
On 2017-07-31 16:44, Fabian Greffrath wrote:
> I think the following/something similar needs to be done (in GIT
> language):
>
> - Create a branch off of the 3.99.5 release
> - Make this branch the new "master" branch
> - Branch out the changes to the psycho-acoustic model into a dedicated 
>   feature branch
> - Release 3.99.6


The approach looks good to me. Robert, would you agree with branching
your changes into a branch, and "reverting" the trunk to 3.99.5 state,
so that security patches could be applied?

If we agree on that, the next step will be to find someone with some
time to dedicate to this. The main issue of "legacy" Lame developpers is
really the lack of time...

There is a possibility that the would have a bit of time to do it in
september (even though that's not 100% sure), but for sure I won't have
available in august.

Regards,

--
Gabriel Bouvigne

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on

Rogério Brito-4
Hi.

Sorry for the semi-unformatted reply. I'm in a hurry right now, but I
just wanted to say a few words...

On Mon, Jul 31, 2017 at 2:07 PM,  <[hidden email]> wrote:

> On 2017-07-31 16:44, Fabian Greffrath wrote:
>>
>> I think the following/something similar needs to be done (in GIT
>> language):
>>
>> - Create a branch off of the 3.99.5 release
>> - Make this branch the new "master" branch
>> - Branch out the changes to the psycho-acoustic model into a dedicated
>>   feature branch
>> - Release 3.99.6

I had that in mind for some time already, but my lack of CVS-fu makes this hard.

I'm sorry if this has already been mentioned here, but this seems like
an excellent opportunity to switch to git. My unofficial mirror on
github has some followers and I think that we could use that as a
learning experience (so that the repository layout doesn't end up as
ugly as I came up with :-)).

We can also take this opportunity to welcome some of the code in
github and ask people to submit pull requests to the main tree and try
to make some releases.

Note that I am not (yet) proposing to switch to github, but only to
switch to git. Any repository on github, at least as a first
approximation, would be a mirror of whatever we decide is the main
repository.

Yes, I am offering to do part of this work. What do you guys think?


Thanks in advance for all the talk so far (which I have not had the
opportunity to follow),

Rogério Brito.


> The approach looks good to me. Robert, would you agree with branching your
> changes into a branch, and "reverting" the trunk to 3.99.5 state, so that
> security patches could be applied?
>
> If we agree on that, the next step will be to find someone with some time to
> dedicate to this. The main issue of "legacy" Lame developpers is really the
> lack of time...
>
> There is a possibility that the would have a bit of time to do it in
> september (even though that's not 100% sure), but for sure I won't have
> available in august.
>
> Regards,
>
> --
> Gabriel Bouvigne
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Lame-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/lame-dev



--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on

Thomas Orgis
Am Mon, 31 Jul 2017 17:25:03 -0300
schrieb Rogério Brito <[hidden email]>:

> I'm sorry if this has already been mentioned here, but this seems like
> an excellent opportunity to switch to git.

An easier migration would be to subversion, though. It supports proper
branching and merging nowadays and the migration from CVS is very well
established, along with easy migration of the mind as the command set
is very similar. There is an easy-to-grasp (IMHO) methaphor of a file
system tree where branches and tags are just copies with some projected
semantics. Version History is linear with simple revision numbers and
not easily meddled with, like CVS.

Also you can version other stuff outside the actual code in
trunk or branches. For mpg123, I simply version the website along
mpg123 itself in the same subversion repository. You don't want to see
that when checking out the code for hacking or in a release tarball.

I know everyone is moving to git, even github, and the kids give you an
unbelieving stare when you mention revision control as a general
concept and not just another name for git. Git is very powerful and it
very well suits large active projects with many developers working
together, but not every use-case needs that. Other revision control
systems have advantages over git, too. Maybe even the simple stuff like
being able to version empty directories, or checking out only parts of
a tree. Or have a revision number that you can understand as a point in
time.

I guess lame will move to git like everybody else. I just wanted to
voice that there indeed are alternatives (of course also the other
distributed ones). I don't like monopolies and for some reason, despite
somewhat working with it for about 10 years now (other projects than
mpg123), I still don't really like git. I admit that I also would
welcome a move from CVS as I only briefly used it before jumping to
Subversion. But given the low expected rate of change of the very
mature project, there is no pressing need at all to change development
tools when the main issue is lack of anyone doing work to begin with.

If the only one to actually contribute is doing the migration to be
able to bear working on lame, then I see the point, though;-) After
all, the tools are secondary. Code counts.

I am still trying to get my head into the mpglib usage in lame. One
possible showstopper is that you want samples as unclipped double numbers on
occasion. I hope I can change that to single-precision float. You get
that from a standard build of libmpg123, while double would mean that
we need to configure a copy of libmpg123 in-tree. Any real use case for
double-precision PCM samples?


Alrighty then,

Thomas


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on

bouvigne
On 2017-07-31 23:11, Thomas Orgis wrote:

> Am Mon, 31 Jul 2017 17:25:03 -0300
> schrieb Rogério Brito <[hidden email]>:
>
>> I'm sorry if this has already been mentioned here, but this seems like
>> an excellent opportunity to switch to git.
>
> An easier migration would be to subversion, though. It supports proper
> branching and merging nowadays and the migration from CVS is very well
> established, along with easy migration of the mind as the command set
> is very similar.

I am going to disapoint everyone, and really question the
benefits/efforts ratio in a migration away from CVS.
Of course, CVS is obsolete within the versionning tools, and for sure
it's not hype/trendy.
However, if the last Lame release is from 5 years ago, this is clearly
not because of the versionning tool, but because of the lack of
time/willingness to invest time in Lame.

My feeling is that switching tool will likely require more efforts than
moving current head to a branch in CVS + correcting the issues reported
on libmp3lame.

However, my last commit on Lame dates back from 2009, so I'm not an
active commiter either :-)


> I am still trying to get my head into the mpglib usage in lame. One
> possible showstopper is that you want samples as unclipped double
> numbers on
> occasion. I hope I can change that to single-precision float. You get
> that from a standard build of libmpg123, while double would mean that
> we need to configure a copy of libmpg123 in-tree. Any real use case for
> double-precision PCM samples?

I think that decoding to float instead of double would be fine, but
beware of the interfaces: if Lame is using double later on on those
inputs, you'd have to handle the conversion.

Regards,

--
Gabriel Bouvigne

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on

Alexander Leidinger
Quoting [hidden email] (from Tue, 01 Aug 2017 10:18:03 +0200):

> On 2017-07-31 23:11, Thomas Orgis wrote:
>> Am Mon, 31 Jul 2017 17:25:03 -0300
>> schrieb Rogério Brito <[hidden email]>:
>>
>>> I'm sorry if this has already been mentioned here, but this seems like
>>> an excellent opportunity to switch to git.
>>
>> An easier migration would be to subversion, though. It supports proper
>> branching and merging nowadays and the migration from CVS is very well
>> established, along with easy migration of the mind as the command set
>> is very similar.
>
> I am going to disapoint everyone, and really question the  
> benefits/efforts ratio in a migration away from CVS.
> Of course, CVS is obsolete within the versionning tools, and for  
> sure it's not hype/trendy.
> However, if the last Lame release is from 5 years ago, this is  
> clearly not because of the versionning tool, but because of the lack  
> of time/willingness to invest time in Lame.

I agree and disagree at the same time. :)

For those people which have write access to LAME already, the point is  
not the tool, it's time.
For the new kids on the block, git matters. It's the tool they know,  
it's distributed so that they first can play around in their own repo  
(not that you couldn't to something like that in CVS in some manual  
way, but they usually only know how to do it in git).

I agree with Thomas, that it doesn't has to be git (I prefer SVN), but  
on the other hand, if we switch, we should switch to git just because  
the user base of git is bigger (not based on facts, just my personal  
impression/opinion).

> My feeling is that switching tool will likely require more efforts  
> than moving current head to a branch in CVS + correcting the issues  
> reported on libmp3lame.

Well... what about first doing a summer-cleaning (fixing the issues),  
and then switching (if there is a volunteer, why not?) for the  
hope/benefit of maybe attracting new blood?

One more thing which may play a role here... we don't really have the  
release process written down, do we? And not everyone knows what needs  
to be done where with which account/password. Everyone would have to  
come up with his own way... like changing the version, updating the  
ChangeLog (I would have to check myself now how... I think I have a  
script for this) running "make distribution" (or is it "make  
distrib"?) and then... the generated tarball needs to be uploaded  
somewhere... and then I would wonder what else has to be done  
(something in the SF webinterface?).

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on

Fabian Greffrath
In reply to this post by bouvigne
[hidden email] wrote:
> However, if the last Lame release is from 5 years ago, this is clearly
> not because of the versionning tool, but because of the lack of
> time/willingness to invest time in Lame.

I tend to disagree here! GIT has become so popular exactly because it
makes it so easy to start contributing: You clone a repo, create a branch,
commit your changes and push them.

For me, the sheer prospective of having to fight around with CVS causes me
to not even check out the repo and move along to another project instead.

If there is a right time to do VCS switch, it should be now.

 - Fabian



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: prominent message on website about "use only on

Thomas Orgis
Disclaimer: Pointless ranting about revision control systems where
discussion about technical issues is demanded. You may skip reading
this mail if you are short on time and not in it for the fun of it;-)

Am Tue, 1 Aug 2017 11:27:18 +0200
schrieb "Fabian Greffrath" <[hidden email]>:

> I tend to disagree here! GIT has become so popular exactly because it
> makes it so easy to start contributing: You clone a repo, create a branch,
> commit your changes and push them.

It only really became easy enough with github. Plain git needs you to
get the mental image of all the stuff happening behind the scenes to
survive your first merge conflict (then you're off haunting
stackoverflow for the magic incanations to fix things). The one thing I
really miss in Subversion is offline commits … which are in the
pipeline since some time now. Some local messing with history since
last commit (push) is indeed valuable, but I really like my official
history being monotonic and unchanging unless some real effort is
excerted (dump, mangle, re-create repo).

> For me, the sheer prospective of having to fight around with CVS causes me
> to not even check out the repo and move along to another project instead.

Not trying to insult you personally, but I think it is sad that someone
who actually has the ability to work on Lame code (which needs more
skill than your average web framework) should already give up at the option of

a) Doing the CVS dance. Just copy the lines mentioned under ‘getting the
   source code’. Edit. do `cvs diff > my.patch` and attach the patch to a
   mail or

b) Just grabbing the source tarball (e.g. from the debian src package),
   edit, diff for a patch, send patch.

But yes, it is a fact that CVS is a barrier for people who only know
git. And one might attract more (good?) developers if switching from
it. But even then, what Lame needs is a cleanup of the current
situation (not sexy, not for newcomers) and after that mainly dutiful
maintenance (boring). Is there big new functionality expected? Are we
adding MP3 surround which nobody uses? I entertain the idea that Lame
is basically finished apart from bug fixes. You might want to add
intensity stereo coding for completeness sake (I had to hunt down
mp3enc in an old VM to get those sample files for libmpg123), but how
much is there to play around and get exited about?

In the end there will be about one person doing the job, and it's of
course fine that this person eventually migrates the tools to what
suits them. Who does the work does the calls.

If someone has scientific ideas about a new psy model, that's so
involved that I have a hard time imagining that having to learn
$ANY_RCS_TOOL is a serious barrier above that.

To get back to the point: I will hack libmpg123 usage into lame over
the weekend, hopefully. I plan to also dig into mp3x to get mpglib
truly replaced. I will then do a `cvs diff` and send the resulting
patch to this list, the traditional way.


Alrighty then,

Thomas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
12