* [gentoo-dev] Idea for a new project: gentoo-libs @ 2018-06-23 2:50 Marty E. Plummer 2018-06-23 2:57 ` Marty E. Plummer ` (4 more replies) 0 siblings, 5 replies; 32+ messages in thread From: Marty E. Plummer @ 2018-06-23 2:50 UTC (permalink / raw To: gentoo-dev So, as you may be aware I've been doing some work on moving bzip2 to an autotools based build. Recently I've ran into app-crypt/mhash, which is in a semi-abandoned state (talking with the maintainer on twitter atm), and I was thinking it may be a good idea to set up a project for keeping these semi-abandoned and really-abandoned libraries and projects up to date and such. Basically, an upstream for packages who's upstream is either uncontactable or is otherwise not accepting bug fixes and patches. So far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure there are others in this state. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 2:50 [gentoo-dev] Idea for a new project: gentoo-libs Marty E. Plummer @ 2018-06-23 2:57 ` Marty E. Plummer 2018-06-23 13:05 ` Jonas Stein 2018-06-23 7:22 ` Michał Górny ` (3 subsequent siblings) 4 siblings, 1 reply; 32+ messages in thread From: Marty E. Plummer @ 2018-06-23 2:57 UTC (permalink / raw To: gentoo-dev On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote: > So, as you may be aware I've been doing some work on moving bzip2 to an > autotools based build. Recently I've ran into app-crypt/mhash, which is > in a semi-abandoned state (talking with the maintainer on twitter atm), > and I was thinking it may be a good idea to set up a project for keeping > these semi-abandoned and really-abandoned libraries and projects up to > date and such. > > Basically, an upstream for packages who's upstream is either > uncontactable or is otherwise not accepting bug fixes and patches. So > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure > there are others in this state. > Or... call it proxy-upstream, to be in line with the current proxy-maint setup? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 2:57 ` Marty E. Plummer @ 2018-06-23 13:05 ` Jonas Stein 2018-08-05 16:55 ` Richard Yao 0 siblings, 1 reply; 32+ messages in thread From: Jonas Stein @ 2018-06-23 13:05 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 2020 bytes --] On 2018-06-23 04:57, Marty E. Plummer wrote: > On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote: >> So, as you may be aware I've been doing some work on moving bzip2 to an >> autotools based build. Recently I've ran into app-crypt/mhash, which is >> in a semi-abandoned state (talking with the maintainer on twitter atm), >> and I was thinking it may be a good idea to set up a project for keeping >> these semi-abandoned and really-abandoned libraries and projects up to >> date and such. >> >> Basically, an upstream for packages who's upstream is either >> uncontactable or is otherwise not accepting bug fixes and patches. So >> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure >> there are others in this state. >> > Or... call it proxy-upstream, to be in line with the current proxy-maint > setup? Please do not call it proxy-*. The invented word proxymaintainer and proxiedmaintainer are not usefull. They get always mixed, and are not understood outside of Gentoo. assistant developer or trainee developer would have been much more useful. Beside the naming I like the idea, that you want to take care for all abandoned libs. Please note, that you can not generate more manpower by creating a project. In 2015 I calculated ===================================================== (Number of developers) / (Number of Projects) < 1.4 ===================================================== Which explains, why most projects today are run by mostly one active person. If you find an important library, where upstream is dead, fork it and take responsibility for it. It makes no sense to make a pool of dead and important software and delegate the responsibility to a team where nobody really knows the software. Better pick a library, communicate with maintainers of the other distributions and fork it. Keep the library alive in the fork. It is important for the security to let dead projects die. -- Best, Jonas [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 981 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 13:05 ` Jonas Stein @ 2018-08-05 16:55 ` Richard Yao 0 siblings, 0 replies; 32+ messages in thread From: Richard Yao @ 2018-08-05 16:55 UTC (permalink / raw To: gentoo-dev > On Jun 23, 2018, at 9:05 AM, Jonas Stein <jstein@gentoo.org> wrote: > >> On 2018-06-23 04:57, Marty E. Plummer wrote: >>> On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote: >>> So, as you may be aware I've been doing some work on moving bzip2 to an >>> autotools based build. Recently I've ran into app-crypt/mhash, which is >>> in a semi-abandoned state (talking with the maintainer on twitter atm), >>> and I was thinking it may be a good idea to set up a project for keeping >>> these semi-abandoned and really-abandoned libraries and projects up to >>> date and such. >>> >>> Basically, an upstream for packages who's upstream is either >>> uncontactable or is otherwise not accepting bug fixes and patches. So >>> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure >>> there are others in this state. >>> >> Or... call it proxy-upstream, to be in line with the current proxy-maint >> setup? > > Please do not call it proxy-*. > The invented word proxymaintainer and proxiedmaintainer are not usefull. > They get always mixed, and are not understood outside of Gentoo. > assistant developer or trainee developer would have been much more useful. Until we have a better name, why not call it the GPL project? GPL meaning: Gentoo POSIX Libraries Misunderstandings from the obvious acronym collision aside, I think the name GPL Project would be more appealing to outsiders than “proxy-libs”, which I agree would be misunderstood in the worst possible ways. > > Beside the naming I like the idea, that you want to take care for all > abandoned libs. > > Please note, that you can not generate more manpower by creating a > project. In 2015 I calculated In the case of creating a new upstream for key libraries shared by distributions, I disagree. As long as other distribution maintainers get on board, the deduplication of effort will result in more man power. > > ===================================================== > > (Number of developers) / (Number of Projects) < 1.4 > > ===================================================== > > Which explains, why most projects today are run by mostly one active person. > > If you find an important library, where upstream is dead, fork it and > take responsibility for it. I will call this point 1 of yours. That sounds like what this project is intended to do. > > It makes no sense to make a pool of dead and important software and > delegate the responsibility to a team where nobody really knows the > software. I will call this point 2 of yours. It depends on the importance of the software. > > Better pick a library, communicate with maintainers of the other > distributions and fork it. Keep the library alive in the fork. I feel like this is the same as 1. > > It is important for the security to let dead projects die. I feel like this is 2, and that it contradicts 1. > > -- > Best, > Jonas > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 2:50 [gentoo-dev] Idea for a new project: gentoo-libs Marty E. Plummer 2018-06-23 2:57 ` Marty E. Plummer @ 2018-06-23 7:22 ` Michał Górny 2018-06-23 7:30 ` Marty E. Plummer 2018-06-23 7:43 ` Mikle Kolyada ` (2 subsequent siblings) 4 siblings, 1 reply; 32+ messages in thread From: Michał Górny @ 2018-06-23 7:22 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1038 bytes --] W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. Plummer napisał: > So, as you may be aware I've been doing some work on moving bzip2 to an > autotools based build. Recently I've ran into app-crypt/mhash, which is > in a semi-abandoned state (talking with the maintainer on twitter atm), > and I was thinking it may be a good idea to set up a project for keeping > these semi-abandoned and really-abandoned libraries and projects up to > date and such. > > Basically, an upstream for packages who's upstream is either > uncontactable or is otherwise not accepting bug fixes and patches. So > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure > there are others in this state. > So in order to fix problem of semi-abandoned packages, you're creating an indirect herd-like entity that will soon be semi-abandoned itself because people will be dumping random packages into it and afterwards nobody will claim responsibility for them. -- Best regards, Michał Górny [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 963 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 7:22 ` Michał Górny @ 2018-06-23 7:30 ` Marty E. Plummer 2018-06-23 7:37 ` Michał Górny 2018-06-23 10:59 ` Alec Warner 0 siblings, 2 replies; 32+ messages in thread From: Marty E. Plummer @ 2018-06-23 7:30 UTC (permalink / raw To: gentoo-dev On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote: > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. > Plummer napisał: > > So, as you may be aware I've been doing some work on moving bzip2 to an > > autotools based build. Recently I've ran into app-crypt/mhash, which is > > in a semi-abandoned state (talking with the maintainer on twitter atm), > > and I was thinking it may be a good idea to set up a project for keeping > > these semi-abandoned and really-abandoned libraries and projects up to > > date and such. > > > > Basically, an upstream for packages who's upstream is either > > uncontactable or is otherwise not accepting bug fixes and patches. So > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure > > there are others in this state. > > > > So in order to fix problem of semi-abandoned packages, you're creating > an indirect herd-like entity that will soon be semi-abandoned itself > because people will be dumping random packages into it and afterwards > nobody will claim responsibility for them. > > -- > Best regards, > Michał Górny No, I mean for packages which are important enough in gentoo to warrant such treatment. For instance, every email I've tried for bzip2's upstream bounced or recieved no reply. That, I assume, is important enough to actually maintain and improve. Any other library which may be as important which are as inactive would be added. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 7:30 ` Marty E. Plummer @ 2018-06-23 7:37 ` Michał Górny 2018-06-23 10:59 ` Alec Warner 1 sibling, 0 replies; 32+ messages in thread From: Michał Górny @ 2018-06-23 7:37 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1860 bytes --] W dniu sob, 23.06.2018 o godzinie 02∶30 -0500, użytkownik Marty E. Plummer napisał: > On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote: > > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. > > Plummer napisał: > > > So, as you may be aware I've been doing some work on moving bzip2 to an > > > autotools based build. Recently I've ran into app-crypt/mhash, which is > > > in a semi-abandoned state (talking with the maintainer on twitter atm), > > > and I was thinking it may be a good idea to set up a project for keeping > > > these semi-abandoned and really-abandoned libraries and projects up to > > > date and such. > > > > > > Basically, an upstream for packages who's upstream is either > > > uncontactable or is otherwise not accepting bug fixes and patches. So > > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure > > > there are others in this state. > > > > > > > So in order to fix problem of semi-abandoned packages, you're creating > > an indirect herd-like entity that will soon be semi-abandoned itself > > because people will be dumping random packages into it and afterwards > > nobody will claim responsibility for them. > > > > -- > > Best regards, > > Michał Górny > > No, I mean for packages which are important enough in gentoo to warrant > such treatment. For instance, every email I've tried for bzip2's > upstream bounced or recieved no reply. That, I assume, is important > enough to actually maintain and improve. Any other library which may be > as important which are as inactive would be added. Sounds like you're going to take over half of base-system ;-). I really prefer having single dedicated individuals for that kind of stuff. Projects just blur the responsibility. -- Best regards, Michał Górny [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 963 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 7:30 ` Marty E. Plummer 2018-06-23 7:37 ` Michał Górny @ 2018-06-23 10:59 ` Alec Warner 2018-08-05 16:45 ` Richard Yao 1 sibling, 1 reply; 32+ messages in thread From: Alec Warner @ 2018-06-23 10:59 UTC (permalink / raw To: Gentoo Dev [-- Attachment #1: Type: text/plain, Size: 1772 bytes --] On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer <hanetzer@startmail.com> wrote: > On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote: > > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. > > Plummer napisał: > > > So, as you may be aware I've been doing some work on moving bzip2 to an > > > autotools based build. Recently I've ran into app-crypt/mhash, which is > > > in a semi-abandoned state (talking with the maintainer on twitter atm), > > > and I was thinking it may be a good idea to set up a project for > keeping > > > these semi-abandoned and really-abandoned libraries and projects up to > > > date and such. > > > > > > Basically, an upstream for packages who's upstream is either > > > uncontactable or is otherwise not accepting bug fixes and patches. So > > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure > > > there are others in this state. > > > > > > > So in order to fix problem of semi-abandoned packages, you're creating > > an indirect herd-like entity that will soon be semi-abandoned itself > > because people will be dumping random packages into it and afterwards > > nobody will claim responsibility for them. > > > > -- > > Best regards, > > Michał Górny > > No, I mean for packages which are important enough in gentoo to warrant > such treatment. For instance, every email I've tried for bzip2's > upstream bounced or recieved no reply. That, I assume, is important > enough to actually maintain and improve. Any other library which may be > as important which are as inactive would be added. > > I suspect this might be better done in the Linux foundation itself as they have staffing for core components that everyone is using. -A [-- Attachment #2: Type: text/html, Size: 2513 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 10:59 ` Alec Warner @ 2018-08-05 16:45 ` Richard Yao 2018-08-05 17:01 ` Alec Warner 0 siblings, 1 reply; 32+ messages in thread From: Richard Yao @ 2018-08-05 16:45 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2633 bytes --] > On Jun 23, 2018, at 6:59 AM, Alec Warner <antarus@gentoo.org> wrote: > > > >> On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer <hanetzer@startmail.com> wrote: >> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote: >> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. >> > Plummer napisał: >> > > So, as you may be aware I've been doing some work on moving bzip2 to an >> > > autotools based build. Recently I've ran into app-crypt/mhash, which is >> > > in a semi-abandoned state (talking with the maintainer on twitter atm), >> > > and I was thinking it may be a good idea to set up a project for keeping >> > > these semi-abandoned and really-abandoned libraries and projects up to >> > > date and such. >> > > >> > > Basically, an upstream for packages who's upstream is either >> > > uncontactable or is otherwise not accepting bug fixes and patches. So >> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure >> > > there are others in this state. >> > > >> > >> > So in order to fix problem of semi-abandoned packages, you're creating >> > an indirect herd-like entity that will soon be semi-abandoned itself >> > because people will be dumping random packages into it and afterwards >> > nobody will claim responsibility for them. >> > >> > -- >> > Best regards, >> > Michał Górny >> >> No, I mean for packages which are important enough in gentoo to warrant >> such treatment. For instance, every email I've tried for bzip2's >> upstream bounced or recieved no reply. That, I assume, is important >> enough to actually maintain and improve. Any other library which may be >> as important which are as inactive would be added. >> > > I suspect this might be better done in the Linux foundation itself as they have staffing for core components that everyone is using. This would put decision making power into the hands of bureaucrats. I would rather it remain in a community of volunteers. I consider upstream development efforts by Gentoo developers to be beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a priority quite like it affecting a key upstream developer in his day to day life. Also, the Linux Foundation is not embarking on such a project and we clearly have someone willing to try, so I say that we should go for it. Having people that wish to take a more active role in upstream development would not make us any worse off. It is their time to volunteer, so it is not like they will volunteer it for something else if we discourage them. > > -A > > > [-- Attachment #2: Type: text/html, Size: 3731 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-08-05 16:45 ` Richard Yao @ 2018-08-05 17:01 ` Alec Warner 2018-08-05 17:16 ` M. J. Everitt ` (2 more replies) 0 siblings, 3 replies; 32+ messages in thread From: Alec Warner @ 2018-08-05 17:01 UTC (permalink / raw To: Gentoo Dev [-- Attachment #1: Type: text/plain, Size: 3288 bytes --] On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao <ryao@gentoo.org> wrote: > > > On Jun 23, 2018, at 6:59 AM, Alec Warner <antarus@gentoo.org> wrote: > > > > On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer <hanetzer@startmail.com> > wrote: > >> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote: >> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. >> > Plummer napisał: >> > > So, as you may be aware I've been doing some work on moving bzip2 to >> an >> > > autotools based build. Recently I've ran into app-crypt/mhash, which >> is >> > > in a semi-abandoned state (talking with the maintainer on twitter >> atm), >> > > and I was thinking it may be a good idea to set up a project for >> keeping >> > > these semi-abandoned and really-abandoned libraries and projects up to >> > > date and such. >> > > >> > > Basically, an upstream for packages who's upstream is either >> > > uncontactable or is otherwise not accepting bug fixes and patches. So >> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm >> sure >> > > there are others in this state. >> > > >> > >> > So in order to fix problem of semi-abandoned packages, you're creating >> > an indirect herd-like entity that will soon be semi-abandoned itself >> > because people will be dumping random packages into it and afterwards >> > nobody will claim responsibility for them. >> > >> > -- >> > Best regards, >> > Michał Górny >> >> No, I mean for packages which are important enough in gentoo to warrant >> such treatment. For instance, every email I've tried for bzip2's >> upstream bounced or recieved no reply. That, I assume, is important >> enough to actually maintain and improve. Any other library which may be >> as important which are as inactive would be added. >> >> > I suspect this might be better done in the Linux foundation itself as they > have staffing for core components that everyone is using. > > This would put decision making power into the hands of bureaucrats. I > would rather it remain in a community of volunteers. > Meh, it doesn't hurt to ask there about interest (they certainly fund development of other components.) Its not like they have to accept, or that declining somehow inhibits this development. Part of my frustration is that seemingly "anything open source related can be held in Gentoo" and I'm somewhat against that as I feel it dilutes the Gentoo mission. We are here to make a distribution, not maintain random libraries. If you want to do that feel free; but I don't see a need for that work to be associated with Gentoo. > > I consider upstream development efforts by Gentoo developers to be > beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a > priority quite like it affecting a key upstream developer in his day to day > life. > > > Also, the Linux Foundation is not embarking on such a project and we > clearly have someone willing to try, so I say that we should go for it. > Having people that wish to take a more active role in upstream development > would not make us any worse off. It is their time to volunteer, so it is > not like they will volunteer it for something else if we discourage them. > [-- Attachment #2: Type: text/html, Size: 4743 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-08-05 17:01 ` Alec Warner @ 2018-08-05 17:16 ` M. J. Everitt 2018-08-05 17:24 ` Rich Freeman 2018-08-05 18:06 ` Richard Yao 2 siblings, 0 replies; 32+ messages in thread From: M. J. Everitt @ 2018-08-05 17:16 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1.1: Type: text/plain, Size: 1894 bytes --] On 05/08/18 18:01, Alec Warner wrote [excerpted]: > > > On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao <ryao@gentoo.org > <mailto:ryao@gentoo.org>> wrote: > > > > On Jun 23, 2018, at 6:59 AM, Alec Warner <antarus@gentoo.org > <mailto:antarus@gentoo.org>> wrote: > >> >> I suspect this might be better done in the Linux foundation >> itself as they have staffing for core components that everyone is >> using. > This would put decision making power into the hands of > bureaucrats. I would rather it remain in a community of volunteers. > > > Meh, it doesn't hurt to ask there about interest (they certainly fund > development of other components.) Its not like they have to accept, or > that declining somehow inhibits this development. > > Part of my frustration is that seemingly "anything open source related > can be held in Gentoo" and I'm somewhat against that as I feel it > dilutes the Gentoo mission. We are here to make a distribution, not > maintain random libraries. If you want to do that feel free; but I > don't see a need for that work to be associated with Gentoo. > Maintaining a distro is increasingly becoming more a case of fixing upstream's shortcomings, as they move towards completely-bundled packages instead of thorough testing. Creating distribution packages, especially in a source-based distro like Gentoo, requires quite a lot of testing, and a lot of collating user feedback (in terms of bugs) to make sure that the packages built do actually *work*. So no, whilst it does seem on the surface to be a dilution of effort, if it reduces the overall effort to generate robust packages, and distributes it across multiple distros and developers, whilst co-ordination and communication may prove a new challenge, I think this is complementary to what everyone is trying to achieve. </my2cents> [-- Attachment #1.1.2: Type: text/html, Size: 3777 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-08-05 17:01 ` Alec Warner 2018-08-05 17:16 ` M. J. Everitt @ 2018-08-05 17:24 ` Rich Freeman 2018-08-05 17:31 ` M. J. Everitt 2018-08-05 18:12 ` Richard Yao 2018-08-05 18:06 ` Richard Yao 2 siblings, 2 replies; 32+ messages in thread From: Rich Freeman @ 2018-08-05 17:24 UTC (permalink / raw To: gentoo-dev On Sun, Aug 5, 2018 at 1:01 PM Alec Warner <antarus@gentoo.org> wrote: > > > Part of my frustration is that seemingly "anything open source related > can be held in Gentoo" and I'm somewhat against that as I feel it > dilutes the Gentoo mission. We are here to make a distribution, not > maintain random libraries. If you want to do that feel free; but I > don't see a need for that work to be associated with Gentoo. > Honestly, other than maybe some prestige I don't really get the point of hosting random software in Gentoo either. These days getting a repo on github or any of its 47 competitors is a few clicks. You have zero overhead from a governance standpoint, and a dev can of course stick ebuilds in the main repository with zero interference. It seems a lot cleaner from a copyright/etc standpoint as well. Even openrc is hosted outside of Gentoo these days, which makes perfect sense. With the distro as a whole it is a bit more complex, though honestly I'd love to see us get to a point where the whole thing can be SECURELY hosted entirely off-infra as well, even if we still chose to run our own infra. I just see it as a way to both provide options to our users and ourselves. For the latter, being able to host anything on an outside service means that if some component of infra goes down we could have mirrors already running and pulling from infra, or if for some reason somebody sues us or roots us or whatever we can pick up and move without much fuss. Running your own wiki/bugzilla/lists/etc was about the only way to do things in the 90s/etc, but these days there are other options... -- Rich ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-08-05 17:24 ` Rich Freeman @ 2018-08-05 17:31 ` M. J. Everitt 2018-08-05 18:12 ` Richard Yao 1 sibling, 0 replies; 32+ messages in thread From: M. J. Everitt @ 2018-08-05 17:31 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 1825 bytes --] On 05/08/18 18:24, Rich Freeman wrote: > On Sun, Aug 5, 2018 at 1:01 PM Alec Warner <antarus@gentoo.org> wrote: >> >> Part of my frustration is that seemingly "anything open source related >> can be held in Gentoo" and I'm somewhat against that as I feel it >> dilutes the Gentoo mission. We are here to make a distribution, not >> maintain random libraries. If you want to do that feel free; but I >> don't see a need for that work to be associated with Gentoo. >> > Honestly, other than maybe some prestige I don't really get the point > of hosting random software in Gentoo either. These days getting a > repo on github or any of its 47 competitors is a few clicks. You have > zero overhead from a governance standpoint, and a dev can of course > stick ebuilds in the main repository with zero interference. It seems > a lot cleaner from a copyright/etc standpoint as well. > > Even openrc is hosted outside of Gentoo these days, which makes perfect sense. > > With the distro as a whole it is a bit more complex, though honestly > I'd love to see us get to a point where the whole thing can be > SECURELY hosted entirely off-infra as well, even if we still chose to > run our own infra. I just see it as a way to both provide options to > our users and ourselves. For the latter, being able to host anything > on an outside service means that if some component of infra goes down > we could have mirrors already running and pulling from infra, or if > for some reason somebody sues us or roots us or whatever we can pick > up and move without much fuss. > > Running your own wiki/bugzilla/lists/etc was about the only way to do > things in the 90s/etc, but these days there are other options... > "Cloud-based Gentoo" - yeah I see *absolutely no issues* with this ... </sarcasm> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-08-05 17:24 ` Rich Freeman 2018-08-05 17:31 ` M. J. Everitt @ 2018-08-05 18:12 ` Richard Yao 2018-08-05 18:35 ` Rich Freeman 1 sibling, 1 reply; 32+ messages in thread From: Richard Yao @ 2018-08-05 18:12 UTC (permalink / raw To: gentoo-dev > On Aug 5, 2018, at 1:24 PM, Rich Freeman <rich0@gentoo.org> wrote: > >> On Sun, Aug 5, 2018 at 1:01 PM Alec Warner <antarus@gentoo.org> wrote: >> >> >> Part of my frustration is that seemingly "anything open source related >> can be held in Gentoo" and I'm somewhat against that as I feel it >> dilutes the Gentoo mission. We are here to make a distribution, not >> maintain random libraries. If you want to do that feel free; but I >> don't see a need for that work to be associated with Gentoo. >> > > Honestly, other than maybe some prestige I don't really get the point > of hosting random software in Gentoo either. These days getting a > repo on github or any of its 47 competitors is a few clicks. You have > zero overhead from a governance standpoint, and a dev can of course > stick ebuilds in the main repository with zero interference. It seems > a lot cleaner from a copyright/etc standpoint as well. Prestige is good. We have prestige from our (myself and a few others) work in upstream ZFS and Gentoo is well respected there. You will not hear binary package zealots bashing Gentoo in ZFS circles. If a sub-project that touches the entire OSS community can be even a tenth as effective as the efforts in ZFS have been in eliminating binary package zealotry, it would be well worth it. > > Even openrc is hosted outside of Gentoo these days, which makes perfect sense. > > With the distro as a whole it is a bit more complex, though honestly > I'd love to see us get to a point where the whole thing can be > SECURELY hosted entirely off-infra as well, even if we still chose to > run our own infra. I just see it as a way to both provide options to > our users and ourselves. For the latter, being able to host anything > on an outside service means that if some component of infra goes down > we could have mirrors already running and pulling from infra, or if > for some reason somebody sues us or roots us or whatever we can pick > up and move without much fuss. > > Running your own wiki/bugzilla/lists/etc was about the only way to do > things in the 90s/etc, but these days there are other options... > > -- > Rich > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-08-05 18:12 ` Richard Yao @ 2018-08-05 18:35 ` Rich Freeman 2018-08-05 20:49 ` Richard Yao 0 siblings, 1 reply; 32+ messages in thread From: Rich Freeman @ 2018-08-05 18:35 UTC (permalink / raw To: gentoo-dev On Sun, Aug 5, 2018 at 2:12 PM Richard Yao <ryao@gentoo.org> wrote: > > > Prestige is good. We have prestige from our (myself and a few others) work in upstream ZFS and Gentoo is well respected there. Sure, but ZFS on Linux isn't a Gentoo project. I'm not saying people who are Gentoo devs can't also do other things. Lots of Gentoo devs are involved in lots of stuff that gets a fair bit of respect. OpenRC is a big example of this. From time to time I bump into signs of Gentoo on upstream projects (just today that included SoapySDRPlay). Also, this gives us an opportunity to set an example, in helping to ensure the upstream project is maintained in a distro-friendly manner where Gentoo is a first class citizen. I'm not saying that stuff like this should be banned from infra. It just seems like an unnecessary constraint all-around. It means that the project has to generally follow Gentoo policies/etc, and is limited to the tools we provide. Just something to think about... -- Rich ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-08-05 18:35 ` Rich Freeman @ 2018-08-05 20:49 ` Richard Yao 0 siblings, 0 replies; 32+ messages in thread From: Richard Yao @ 2018-08-05 20:49 UTC (permalink / raw To: gentoo-dev > On Aug 5, 2018, at 2:35 PM, Rich Freeman <rich0@gentoo.org> wrote: > >> On Sun, Aug 5, 2018 at 2:12 PM Richard Yao <ryao@gentoo.org> wrote: >> >> >> Prestige is good. We have prestige from our (myself and a few others) work in upstream ZFS and Gentoo is well respected there. > > Sure, but ZFS on Linux isn't a Gentoo project. > > I'm not saying people who are Gentoo devs can't also do other things. > Lots of Gentoo devs are involved in lots of stuff that gets a fair bit > of respect. OpenRC is a big example of this. From time to time I bump > into signs of Gentoo on upstream projects (just today that included > SoapySDRPlay). > > Also, this gives us an opportunity to set an example, in helping to > ensure the upstream project is maintained in a distro-friendly manner > where Gentoo is a first class citizen. > > I'm not saying that stuff like this should be banned from infra. It > just seems like an unnecessary constraint all-around. It means that > the project has to generally follow Gentoo policies/etc, and is > limited to the tools we provide. Just something to think about... Which policies would those be? The upstream projects that we do have as Gentoo sub-projects seem to have plenty of freedom. > > > -- > Rich > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-08-05 17:01 ` Alec Warner 2018-08-05 17:16 ` M. J. Everitt 2018-08-05 17:24 ` Rich Freeman @ 2018-08-05 18:06 ` Richard Yao 2 siblings, 0 replies; 32+ messages in thread From: Richard Yao @ 2018-08-05 18:06 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 3642 bytes --] > On Aug 5, 2018, at 1:01 PM, Alec Warner <antarus@gentoo.org> wrote: > > > >> On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao <ryao@gentoo.org> wrote: >> >> >>> On Jun 23, 2018, at 6:59 AM, Alec Warner <antarus@gentoo.org> wrote: >>> >>> >>> >>>> On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer <hanetzer@startmail.com> wrote: >>>> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote: >>>> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. >>>> > Plummer napisał: >>>> > > So, as you may be aware I've been doing some work on moving bzip2 to an >>>> > > autotools based build. Recently I've ran into app-crypt/mhash, which is >>>> > > in a semi-abandoned state (talking with the maintainer on twitter atm), >>>> > > and I was thinking it may be a good idea to set up a project for keeping >>>> > > these semi-abandoned and really-abandoned libraries and projects up to >>>> > > date and such. >>>> > > >>>> > > Basically, an upstream for packages who's upstream is either >>>> > > uncontactable or is otherwise not accepting bug fixes and patches. So >>>> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure >>>> > > there are others in this state. >>>> > > >>>> > >>>> > So in order to fix problem of semi-abandoned packages, you're creating >>>> > an indirect herd-like entity that will soon be semi-abandoned itself >>>> > because people will be dumping random packages into it and afterwards >>>> > nobody will claim responsibility for them. >>>> > >>>> > -- >>>> > Best regards, >>>> > Michał Górny >>>> >>>> No, I mean for packages which are important enough in gentoo to warrant >>>> such treatment. For instance, every email I've tried for bzip2's >>>> upstream bounced or recieved no reply. That, I assume, is important >>>> enough to actually maintain and improve. Any other library which may be >>>> as important which are as inactive would be added. >>>> >>> >>> I suspect this might be better done in the Linux foundation itself as they have staffing for core components that everyone is using. >> This would put decision making power into the hands of bureaucrats. I would rather it remain in a community of volunteers. > > Meh, it doesn't hurt to ask there about interest (they certainly fund development of other components.) Its not like they have to accept, or that declining somehow inhibits this development. > > Part of my frustration is that seemingly "anything open source related can be held in Gentoo" and I'm somewhat against that as I feel it dilutes the Gentoo mission. We are here to make a distribution, not maintain random libraries. If you want to do that feel free; but I don't see a need for that work to be associated with Gentoo. This could just be done as a downstream effort that carries patches without a subproject, but structuring it as a subproject would be a call for collaboration with other distributions, which would ultimately benefit us. > >> >> I consider upstream development efforts by Gentoo developers to be beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a priority quite like it affecting a key upstream developer in his day to day life. >> >> >> Also, the Linux Foundation is not embarking on such a project and we clearly have someone willing to try, so I say that we should go for it. Having people that wish to take a more active role in upstream development would not make us any worse off. It is their time to volunteer, so it is not like they will volunteer it for something else if we discourage them. [-- Attachment #2: Type: text/html, Size: 5426 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 2:50 [gentoo-dev] Idea for a new project: gentoo-libs Marty E. Plummer 2018-06-23 2:57 ` Marty E. Plummer 2018-06-23 7:22 ` Michał Górny @ 2018-06-23 7:43 ` Mikle Kolyada 2018-06-23 8:15 ` Paweł Hajdan, Jr. 2018-06-23 23:52 ` Kent Fredric 2018-06-25 5:59 ` Hanno Böck 4 siblings, 1 reply; 32+ messages in thread From: Mikle Kolyada @ 2018-06-23 7:43 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 941 bytes --] On 23.06.2018 05:50, Marty E. Plummer wrote: > So, as you may be aware I've been doing some work on moving bzip2 to an > autotools based build. Recently I've ran into app-crypt/mhash, which is > in a semi-abandoned state (talking with the maintainer on twitter atm), > and I was thinking it may be a good idea to set up a project for keeping > these semi-abandoned and really-abandoned libraries and projects up to > date and such. But how would it serve gentoo itself? Lots of packages in the distro have dead upstream but still work. Why would you want to make gentoo an upstream area rather than moving a dead project itself, say, to github and do the job there? > > Basically, an upstream for packages who's upstream is either > uncontactable or is otherwise not accepting bug fixes and patches. So > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure > there are others in this state. > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 313 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 7:43 ` Mikle Kolyada @ 2018-06-23 8:15 ` Paweł Hajdan, Jr. 2018-06-23 8:55 ` Marty E. Plummer 0 siblings, 1 reply; 32+ messages in thread From: Paweł Hajdan, Jr. @ 2018-06-23 8:15 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 767 bytes --] On 23/06/2018 09:43, Mikle Kolyada wrote: > But how would it serve gentoo itself? Lots of packages in the distro > have dead upstream but still work. > Why would you want to make gentoo an upstream area rather than moving a > dead project itself, say, > to github and do the job there? +1 I like the idea of taking responsibility for the abandoned packages that are still useful. It's probably not Gentoo-specific, so a distro-neutral way of handling that seems most appropriate. It may even be worth it to coordinate with other distros (and maybe downstreams) so that the new version becomes a standard. Finally, having more than one person on this (to help continuity), and a common platform like GitHub also seem very helpful. Paweł [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 827 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 8:15 ` Paweł Hajdan, Jr. @ 2018-06-23 8:55 ` Marty E. Plummer 2018-06-23 11:06 ` Roy Bamford 0 siblings, 1 reply; 32+ messages in thread From: Marty E. Plummer @ 2018-06-23 8:55 UTC (permalink / raw To: gentoo-dev On Sat, Jun 23, 2018 at 10:15:06AM +0200, Paweł Hajdan, Jr. wrote: > On 23/06/2018 09:43, Mikle Kolyada wrote: > > But how would it serve gentoo itself? Lots of packages in the distro > > have dead upstream but still work. > > Why would you want to make gentoo an upstream area rather than moving a > > dead project itself, say, > > to github and do the job there? > > +1 > > I like the idea of taking responsibility for the abandoned packages that > are still useful. > > It's probably not Gentoo-specific, so a distro-neutral way of handling > that seems most appropriate. > > It may even be worth it to coordinate with other distros (and maybe > downstreams) so that the new version becomes a standard. > > Finally, having more than one person on this (to help continuity), and a > common platform like GitHub also seem very helpful. > > Paweł > Agreed in general; the problem is getting it started at all; difficult to get other distros to join if there is nothing to join. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 8:55 ` Marty E. Plummer @ 2018-06-23 11:06 ` Roy Bamford 0 siblings, 0 replies; 32+ messages in thread From: Roy Bamford @ 2018-06-23 11:06 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1659 bytes --] On 2018.06.23 09:55, Marty E. Plummer wrote: > On Sat, Jun 23, 2018 at 10:15:06AM +0200, Paweł Hajdan, Jr. wrote: > > On 23/06/2018 09:43, Mikle Kolyada wrote: > > > But how would it serve gentoo itself? Lots of packages in the > distro > > > have dead upstream but still work. > > > Why would you want to make gentoo an upstream area rather than > moving a > > > dead project itself, say, > > > to github and do the job there? > > > > +1 > > > > I like the idea of taking responsibility for the abandoned packages > that > > are still useful. > > > > It's probably not Gentoo-specific, so a distro-neutral way of > handling > > that seems most appropriate. > > > > It may even be worth it to coordinate with other distros (and maybe > > downstreams) so that the new version becomes a standard. > > > > Finally, having more than one person on this (to help continuity), > and a > > common platform like GitHub also seem very helpful. > > > > Paweł > > > Agreed in general; the problem is getting it started at all; difficult > to get other distros to join if there is nothing to join. > > > A couple of generalisations. The first solution to unmaintained packages should be to move to an alternative, if that's possible. Gentoo does not have the resource to be upstream for very much for the entire Linux community, a point already made by others. In volunteer groups things get done by those who want to do them. Others join later. I think the quote I'm looking for is "Build it and they will come". -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 2:50 [gentoo-dev] Idea for a new project: gentoo-libs Marty E. Plummer ` (2 preceding siblings ...) 2018-06-23 7:43 ` Mikle Kolyada @ 2018-06-23 23:52 ` Kent Fredric 2018-06-25 5:59 ` Hanno Böck 4 siblings, 0 replies; 32+ messages in thread From: Kent Fredric @ 2018-06-23 23:52 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1779 bytes --] On Fri, 22 Jun 2018 21:50:50 -0500 "Marty E. Plummer" <hanetzer@startmail.com> wrote: > So, as you may be aware I've been doing some work on moving bzip2 to an > autotools based build. Recently I've ran into app-crypt/mhash, which is > in a semi-abandoned state (talking with the maintainer on twitter atm), > and I was thinking it may be a good idea to set up a project for keeping > these semi-abandoned and really-abandoned libraries and projects up to > date and such. > > Basically, an upstream for packages who's upstream is either > uncontactable or is otherwise not accepting bug fixes and patches. So > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure > there are others in this state. It may be worth mentioning that myself and a handful of others are kicking around the idea of creating a "vendorised upstream", which essentially treats all upstreams as unmaintained, and acts as a middle ground between upstream and linux distributions/end users, by re-shipping upstreams code with fixes, in a format similar to upstreams, but with the mentality of a Linux Vendor. Changes to this project would of course be made under the assumption that upstream would one day wake up, and may be interested in adopting some or all of our fixes ( and for upstreams that are currently not actually dead, this may happen sooner than later ) Presently, this is limited in scope to vendorizing CPAN, but it may grow. In concept, this is of course much more work than your idea, but it has a few advantages, particularly with regards to integrating various vendors patches in a single place. But obviously, such a project is somewhat gargantuan, and getting the working concept off the ground is going to take a while :) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-23 2:50 [gentoo-dev] Idea for a new project: gentoo-libs Marty E. Plummer ` (3 preceding siblings ...) 2018-06-23 23:52 ` Kent Fredric @ 2018-06-25 5:59 ` Hanno Böck 2018-06-27 0:03 ` Marty E. Plummer 2018-08-04 8:43 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Andrew Savchenko 4 siblings, 2 replies; 32+ messages in thread From: Hanno Böck @ 2018-06-25 5:59 UTC (permalink / raw To: gentoo-dev On Fri, 22 Jun 2018 21:50:50 -0500 "Marty E. Plummer" <hanetzer@startmail.com> wrote: > So, as you may be aware I've been doing some work on moving bzip2 to > an autotools based build. Recently I've ran into app-crypt/mhash, > which is in a semi-abandoned state (talking with the maintainer on > twitter atm), and I was thinking it may be a good idea to set up a > project for keeping these semi-abandoned and really-abandoned > libraries and projects up to date and such. This is a common problem, however if you want to make this reasonable you wouldn't make it a gentoo thing, but a cross-distro effort. The idea has been tossed around a lot, but noone yet started implementing it. However keeping things alive may not always be the right option. There's a reason mcrypt is abandoned. It's an ancient crypto library, crypto is moving forward, there are better options. THe main user of mcrypt was PHP, and PHP is abandoning it with 7.2. (There are 2 other users in the gentoo tree of libmcrypt, which are both rather obscure packages - nsca and elettra.) -- Hanno Böck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Idea for a new project: gentoo-libs 2018-06-25 5:59 ` Hanno Böck @ 2018-06-27 0:03 ` Marty E. Plummer 2018-08-04 8:43 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Andrew Savchenko 1 sibling, 0 replies; 32+ messages in thread From: Marty E. Plummer @ 2018-06-27 0:03 UTC (permalink / raw To: gentoo-dev On Mon, Jun 25, 2018 at 07:59:47AM +0200, Hanno Böck wrote: > On Fri, 22 Jun 2018 21:50:50 -0500 > "Marty E. Plummer" <hanetzer@startmail.com> wrote: > > > So, as you may be aware I've been doing some work on moving bzip2 to > > an autotools based build. Recently I've ran into app-crypt/mhash, > > which is in a semi-abandoned state (talking with the maintainer on > > twitter atm), and I was thinking it may be a good idea to set up a > > project for keeping these semi-abandoned and really-abandoned > > libraries and projects up to date and such. > > This is a common problem, however if you want to make this reasonable > you wouldn't make it a gentoo thing, but a cross-distro effort. The > idea has been tossed around a lot, but noone yet started implementing > it. > > However keeping things alive may not always be the right option. > There's a reason mcrypt is abandoned. It's an ancient crypto library, mhash, not mcrypt. I've not loked at mcrypt at all yet, so I have no ideas as to its status. > crypto is moving forward, there are better options. THe main user of > mcrypt was PHP, and PHP is abandoning it with 7.2. (There are 2 other > users in the gentoo tree of libmcrypt, which are both rather obscure > packages - nsca and elettra.) > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > ^ permalink raw reply [flat|nested] 32+ messages in thread
* mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) 2018-06-25 5:59 ` Hanno Böck 2018-06-27 0:03 ` Marty E. Plummer @ 2018-08-04 8:43 ` Andrew Savchenko 2018-08-04 9:51 ` [gentoo-dev] Re: mcrypt status Martin Vaeth ` (2 more replies) 1 sibling, 3 replies; 32+ messages in thread From: Andrew Savchenko @ 2018-08-04 8:43 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1362 bytes --] On Mon, 25 Jun 2018 07:59:47 +0200 Hanno Böck wrote: > On Fri, 22 Jun 2018 21:50:50 -0500 > "Marty E. Plummer" <hanetzer@startmail.com> wrote: > > > So, as you may be aware I've been doing some work on moving bzip2 to > > an autotools based build. Recently I've ran into app-crypt/mhash, > > which is in a semi-abandoned state (talking with the maintainer on > > twitter atm), and I was thinking it may be a good idea to set up a > > project for keeping these semi-abandoned and really-abandoned > > libraries and projects up to date and such. > > This is a common problem, however if you want to make this reasonable > you wouldn't make it a gentoo thing, but a cross-distro effort. The > idea has been tossed around a lot, but noone yet started implementing > it. > > However keeping things alive may not always be the right option. > There's a reason mcrypt is abandoned. It's an ancient crypto library, > crypto is moving forward, there are better options. Do you have any evidence that mcrypt should not be used? Symmetric cryptography is quite conservative and it took years and even decades for algorithms and their implementations to become trusted, so there is nothing wrong in using good old verified software. Actually for local symmetric encryption this is the best tool I know. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [gentoo-dev] Re: mcrypt status 2018-08-04 8:43 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Andrew Savchenko @ 2018-08-04 9:51 ` Martin Vaeth 2018-08-04 10:22 ` Andrew Savchenko 2018-08-04 14:29 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Hanno Böck 2018-08-04 18:05 ` Marty E. Plummer 2 siblings, 1 reply; 32+ messages in thread From: Martin Vaeth @ 2018-08-04 9:51 UTC (permalink / raw To: gentoo-dev Andrew Savchenko <bircoph@gentoo.org> wrote: > > Actually for local symmetric encryption this is the best tool I > know. What is the advantage over gpg --symmetric? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Re: mcrypt status 2018-08-04 9:51 ` [gentoo-dev] Re: mcrypt status Martin Vaeth @ 2018-08-04 10:22 ` Andrew Savchenko 0 siblings, 0 replies; 32+ messages in thread From: Andrew Savchenko @ 2018-08-04 10:22 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 599 bytes --] On Sat, 4 Aug 2018 09:51:14 +0000 (UTC) Martin Vaeth wrote: > Andrew Savchenko <bircoph@gentoo.org> wrote: > > > > Actually for local symmetric encryption this is the best tool I > > know. > > What is the advantage over gpg --symmetric? 1) mcrypt has wider range of algorithms, including gost which I need. 2) gpg-agent sometimes causes too much trouble (by being enforced in gpg2) and I like it more to enter passphares without any agents. xterm can grab screen and that is sufficient for my needs. Other than that gpg -s in nice and good tool. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) 2018-08-04 8:43 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Andrew Savchenko 2018-08-04 9:51 ` [gentoo-dev] Re: mcrypt status Martin Vaeth @ 2018-08-04 14:29 ` Hanno Böck 2018-08-04 15:25 ` Thomas Deutschmann 2018-08-05 4:57 ` Andrew Savchenko 2018-08-04 18:05 ` Marty E. Plummer 2 siblings, 2 replies; 32+ messages in thread From: Hanno Böck @ 2018-08-04 14:29 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1111 bytes --] Hi, On Sat, 4 Aug 2018 11:43:28 +0300 Andrew Savchenko <bircoph@gentoo.org> wrote: > Do you have any evidence that mcrypt should not be used? Well, PHP was as far as I'm aware its main user and PHP has declared mcrypt support to be deprecated a while ago. > Symmetric cryptography is quite conservative and it took years and > even decades for algorithms and their implementations to become > trusted, so there is nothing wrong in using good old verified > software. When it comes to cipher modes the fact that people use decades old modes is a problem. See efail for a prominent example, but there are many less prominent ones. Look at the mcrypt webpage: http://mcrypt.sourceforge.net/ Modes of Operation: CBC CFB CTR ECB OFB NCFB That is a mixture of very insecure (ECB), insecure in most situations (all others) and totally obscure modes. It doesn't include any authenticated encryption modes, which in most situations is what you want to use. -- Hanno Böck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) 2018-08-04 14:29 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Hanno Böck @ 2018-08-04 15:25 ` Thomas Deutschmann 2018-08-05 4:57 ` Andrew Savchenko 1 sibling, 0 replies; 32+ messages in thread From: Thomas Deutschmann @ 2018-08-04 15:25 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 944 bytes --] On 2018-08-04 16:29, Hanno Böck wrote: >> Do you have any evidence that mcrypt should not be used? > Well, PHP was as far as I'm aware its main user and PHP has declared > mcrypt support to be deprecated a while ago. In all fairness: Yes, PHP project has removed ext/mcrypt from core, but they only moved it into an own PECL extension. My point here is, that they did not drop and prune mcrypt from universe due to security vulnerabilities. Anyone interested in this should read the following posting [1]. tl;dr Like most crypto libs, mcrypt isn't easy to use and you will likely do something wrong. In favor of a better solutions which should prevent such a misuse, mcrypt was deprecated. See also: ========= [1] https://why-cant-we-have-nice-things.mwl.be/requests/deprecate-then-remove-mcrypt. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 981 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) 2018-08-04 14:29 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Hanno Böck 2018-08-04 15:25 ` Thomas Deutschmann @ 2018-08-05 4:57 ` Andrew Savchenko 1 sibling, 0 replies; 32+ messages in thread From: Andrew Savchenko @ 2018-08-05 4:57 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1426 bytes --] Hi, On Sat, 4 Aug 2018 07:29:47 -0700 Hanno Böck wrote: > > Symmetric cryptography is quite conservative and it took years and > > even decades for algorithms and their implementations to become > > trusted, so there is nothing wrong in using good old verified > > software. > > When it comes to cipher modes the fact that people use decades old > modes is a problem. See efail for a prominent example, but there > are many less prominent ones. > > Look at the mcrypt webpage: > http://mcrypt.sourceforge.net/ > > Modes of Operation: > > CBC > CFB > CTR > ECB > OFB > NCFB > > That is a mixture of very insecure (ECB), insecure in most situations > (all others) and totally obscure modes. It doesn't include any > authenticated encryption modes, which in most situations is what you > want to use. I want to use mcrypt for local encryption only, therefore I don't really care about MACs. In my use cases modification tampering is easy to detect by other means. ECB is indeed unsafe and must be avoided (hey, openssl supports ECB as well, let's ban it!). CBC is better, but vulnerable to PODDLE, so I agree on avoiding it as well. As for CTR, (N)CFB, (N)OFB there is nothing obscure about them: they are known for decades and are well studied. There are no direct attacks on these modes known aside from detectable tampering possibility. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) 2018-08-04 8:43 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Andrew Savchenko 2018-08-04 9:51 ` [gentoo-dev] Re: mcrypt status Martin Vaeth 2018-08-04 14:29 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Hanno Böck @ 2018-08-04 18:05 ` Marty E. Plummer 2018-08-04 19:22 ` Andrew Savchenko 2 siblings, 1 reply; 32+ messages in thread From: Marty E. Plummer @ 2018-08-04 18:05 UTC (permalink / raw To: gentoo-dev On Sat, Aug 04, 2018 at 11:43:28AM +0300, Andrew Savchenko wrote: > On Mon, 25 Jun 2018 07:59:47 +0200 Hanno Böck wrote: > > On Fri, 22 Jun 2018 21:50:50 -0500 > > "Marty E. Plummer" <hanetzer@startmail.com> wrote: > > > > > So, as you may be aware I've been doing some work on moving bzip2 to > > > an autotools based build. Recently I've ran into app-crypt/mhash, > > > which is in a semi-abandoned state (talking with the maintainer on > > > twitter atm), and I was thinking it may be a good idea to set up a > > > project for keeping these semi-abandoned and really-abandoned > > > libraries and projects up to date and such. > > > > This is a common problem, however if you want to make this reasonable > > you wouldn't make it a gentoo thing, but a cross-distro effort. The > > idea has been tossed around a lot, but noone yet started implementing > > it. > > > > However keeping things alive may not always be the right option. > > There's a reason mcrypt is abandoned. It's an ancient crypto library, > > crypto is moving forward, there are better options. > > Do you have any evidence that mcrypt should not be used? > > Symmetric cryptography is quite conservative and it took years and > even decades for algorithms and their implementations to become > trusted, so there is nothing wrong in using good old verified > software. > > Actually for local symmetric encryption this is the best tool I > know. > > Best regards, > Andrew Savchenko It seems that every last person commenting on this is talking mcrypt, not mhash, which is what I mentioned in the first place. As far as I can tell, these are entirely differnt projects which just happen to have a similar name. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) 2018-08-04 18:05 ` Marty E. Plummer @ 2018-08-04 19:22 ` Andrew Savchenko 0 siblings, 0 replies; 32+ messages in thread From: Andrew Savchenko @ 2018-08-04 19:22 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 487 bytes --] On Sat, 4 Aug 2018 13:05:56 -0500 Marty E. Plummer wrote: [...] > It seems that every last person commenting on this is talking mcrypt, > not mhash, which is what I mentioned in the first place. As far as I can > tell, these are entirely differnt projects which just happen to have a > similar name. Yes, they are. But it this very case I'm interested in mcrypt status, not mhash, that's why I changed the subject field of this discussion. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2018-08-05 20:49 UTC | newest] Thread overview: 32+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-06-23 2:50 [gentoo-dev] Idea for a new project: gentoo-libs Marty E. Plummer 2018-06-23 2:57 ` Marty E. Plummer 2018-06-23 13:05 ` Jonas Stein 2018-08-05 16:55 ` Richard Yao 2018-06-23 7:22 ` Michał Górny 2018-06-23 7:30 ` Marty E. Plummer 2018-06-23 7:37 ` Michał Górny 2018-06-23 10:59 ` Alec Warner 2018-08-05 16:45 ` Richard Yao 2018-08-05 17:01 ` Alec Warner 2018-08-05 17:16 ` M. J. Everitt 2018-08-05 17:24 ` Rich Freeman 2018-08-05 17:31 ` M. J. Everitt 2018-08-05 18:12 ` Richard Yao 2018-08-05 18:35 ` Rich Freeman 2018-08-05 20:49 ` Richard Yao 2018-08-05 18:06 ` Richard Yao 2018-06-23 7:43 ` Mikle Kolyada 2018-06-23 8:15 ` Paweł Hajdan, Jr. 2018-06-23 8:55 ` Marty E. Plummer 2018-06-23 11:06 ` Roy Bamford 2018-06-23 23:52 ` Kent Fredric 2018-06-25 5:59 ` Hanno Böck 2018-06-27 0:03 ` Marty E. Plummer 2018-08-04 8:43 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Andrew Savchenko 2018-08-04 9:51 ` [gentoo-dev] Re: mcrypt status Martin Vaeth 2018-08-04 10:22 ` Andrew Savchenko 2018-08-04 14:29 ` mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs) Hanno Böck 2018-08-04 15:25 ` Thomas Deutschmann 2018-08-05 4:57 ` Andrew Savchenko 2018-08-04 18:05 ` Marty E. Plummer 2018-08-04 19:22 ` Andrew Savchenko
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox