Nobody stepped up to maintain this crypto library which is no longer used by rpm or anything else in Fedora. So the next logical step is to retire this package from rawhide (dist-f9).
I will do that tomorrow.
On Mon, 03 Dec 2007, Tomas Mraz wrote:
Nobody stepped up to maintain this crypto library which is no longer used by rpm or anything else in Fedora. So the next logical step is to retire this package from rawhide (dist-f9).
I've a third party application which depends on beecrypt, so I would claim the ownership of this package at least on devel (maybe co-maintain on other branches). If I don't hear any veto until tomorrow I would go through the defined "Claiming Ownership of an Orphaned Package Procedure".
Greetings, Robert
On Tue, 2008-03-11 at 20:48 +0100, Robert Scheck wrote:
On Mon, 03 Dec 2007, Tomas Mraz wrote:
Nobody stepped up to maintain this crypto library which is no longer used by rpm or anything else in Fedora. So the next logical step is to retire this package from rawhide (dist-f9).
I've a third party application which depends on beecrypt, so I would claim the ownership of this package at least on devel (maybe co-maintain on other branches). If I don't hear any veto until tomorrow I would go through the defined "Claiming Ownership of an Orphaned Package Procedure".
It was already retired - it is removed from CVS in the devel branch. Not that it is impossible to reintroduce it but wouldn't it be possible to port the third party app to other crypto library? The beecrypt upstream also seems almost dead. If it is reintroduced it should pass a review probably because the old beecrypt package was never revieved.
On Tuesday 11 March 2008 03:48:43 pm Robert Scheck wrote:
I've a third party application which depends on beecrypt, so I would claim the ownership of this package at least on devel (maybe co-maintain on other branches).
I'd suggest they port to another library or package beecrypt into their application. We need to stop the proliferation of crypto and try to get it down to 1 or 2 libraries if at all possible.
-Steve
On Tue, 11 Mar 2008, Steve Grubb wrote:
On Tuesday 11 March 2008 03:48:43 pm Robert Scheck wrote:
I've a third party application which depends on beecrypt, so I would claim the ownership of this package at least on devel (maybe co-maintain on other branches).
I'd suggest they port to another library or package beecrypt into their application. We need to stop the proliferation of crypto and try to get it down to 1 or 2 libraries if at all possible.
I heard yourself clearly nominating porting a closed-source ERP system running at Linux from beecrypt to yet another sucking crypto library... :)
Oh and above was just one example. There is even more software waiting for you to got rewritten *g*
Greetings, Robert
On Tue, 2008-03-11 at 21:43 +0100, Robert Scheck wrote:
On Tue, 11 Mar 2008, Steve Grubb wrote:
On Tuesday 11 March 2008 03:48:43 pm Robert Scheck wrote:
I've a third party application which depends on beecrypt, so I would claim the ownership of this package at least on devel (maybe co-maintain on other branches).
I'd suggest they port to another library or package beecrypt into their application. We need to stop the proliferation of crypto and try to get it down to 1 or 2 libraries if at all possible.
I heard yourself clearly nominating porting a closed-source ERP system running at Linux from beecrypt to yet another sucking crypto library... :)
Oh and above was just one example. There is even more software waiting for you to got rewritten *g*
Well for FLOSS at least we could do it. But have you read the second part of Steve's suggestion? That about packaging beecrypt into their application? Of course Fedora will still contain more crypto libraries than 1 or 2 for many future releases but what about other distros? I for example don't see much probability in having beecrypt included in future RHEL releases.
On Tue, Mar 11, 2008 at 09:57:55PM +0100, Tomas Mraz wrote:
Well for FLOSS at least we could do it. But have you read the second part of Steve's suggestion? That about packaging beecrypt into their application? Of course Fedora will still contain more crypto libraries than 1 or 2 for many future releases but what about other distros? I for example don't see much probability in having beecrypt included in future RHEL releases.
Well, I think RHEL has to care about third-party and/or non-FLOSS software even more than Fedora, so I could imagine that RHEL users want to keep beecrypt longer than you think.
On Tue, 11 Mar 2008, Tomas Mraz wrote:
Well for FLOSS at least we could do it. But have you read the second part of Steve's suggestion? That about packaging beecrypt into their application? Of course Fedora will still contain more crypto libraries than 1 or 2 for many future releases but what about other distros? I for example don't see much probability in having beecrypt included in future RHEL releases.
HAHA. Somebody working for Fedora Project which is always telling not to ship a private library but always use the system one suggests such a thing to me? And I don't care about other distributions and well, beecrypt could end up in a future EPEL release - even if I've to maintain there myself ;)
Greetings, Robert
On Tue, Mar 11, 2008 at 1:08 PM, Robert Scheck robert@fedoraproject.org wrote:
HAHA. Somebody working for Fedora Project which is always telling not to ship a private library but always use the system one suggests such a thing to me? And I don't care about other distributions and well, beecrypt could end up in a future EPEL release - even if I've to maintain there myself ;)
If the beecrypt upstream is dead....and you are wanting to do this primarily to support a closed source application that won't be in Fedora.... is maintaining this in Fedora appopriate?
I'm not sure it is. If you un-retire this package, I believe this will be prelude to a discussion concerning whether Fedora should insist on there being an 'active' upstream for the component.
-jef
Jeff Spaleta wrote:
On Tue, Mar 11, 2008 at 1:08 PM, Robert Scheck robert@fedoraproject.org wrote:
HAHA. Somebody working for Fedora Project which is always telling not to ship a private library but always use the system one suggests such a thing to me? And I don't care about other distributions and well, beecrypt could end up in a future EPEL release - even if I've to maintain there myself ;)
If the beecrypt upstream is dead....and you are wanting to do this primarily to support a closed source application that won't be in Fedora.... is maintaining this in Fedora appopriate?
I'm not sure it is. If you un-retire this package, I believe this will be prelude to a discussion concerning whether Fedora should insist on there being an 'active' upstream for the component.
There's some basis for Jef's argument in the "Fedora is not a dumping ground for old, unmaintained software" philosophy. OTOH, the line between no upstream, a little upstream activity, and maintained by the Fedora Packager could get blurry here. So if we're planning on proposing some actual guidelines regarding what is an appropriate level of upstream activity to consider a package for Fedora, a conversation about this is *definitely* needed.
-Toshio
On Thu, 2008-03-13 at 00:33 -0500, Toshio Kuratomi wrote:
Jeff Spaleta wrote:
I'm not sure it is. If you un-retire this package, I believe this will be prelude to a discussion concerning whether Fedora should insist on there being an 'active' upstream for the component.
There's some basis for Jef's argument in the "Fedora is not a dumping ground for old, unmaintained software" philosophy. OTOH, the line between no upstream, a little upstream activity, and maintained by the Fedora Packager could get blurry here. So if we're planning on proposing some actual guidelines regarding what is an appropriate level of upstream activity to consider a package for Fedora, a conversation about this is *definitely* needed.
I distinctly remember a rather long thread on this very topic some time back. And as I remember, defining exactly what an "active upstream" is was a major sticking point.
On Thu, Mar 13, 2008 at 12:33:17AM -0500, Toshio Kuratomi wrote:
There's some basis for Jef's argument in the "Fedora is not a dumping ground for old, unmaintained software" philosophy. OTOH, the line between no upstream, a little upstream activity, and maintained by the Fedora Packager could get blurry here. So if we're planning on proposing some actual guidelines regarding what is an appropriate level of upstream activity to consider a package for Fedora, a conversation about this is *definitely* needed.
This comes up now and then. Some package are completly unmaintained, but also completly stable and don't need an upstream maintainer anymore, so that maintaining them in fedora is right. Some can be maintained by the fedora packager if he has time and skills. For some others not having any upstream is bound to trouble because of potential security issues, and the package should better be dropped from fedora.
I'd say leave it to the packager and use the usual disagreement procedure (complain to the list, escalate to fesco).
-- Pat
On Thursday 13 March 2008 04:38:16 am Patrice Dumas wrote:
I'd say leave it to the packager and use the usual disagreement procedure (complain to the list, escalate to fesco).
What is different about this is that the package in question is crypto related. There are export restrictions and a lot of tracking associated with it. If you leave it in the distribution, eventually someone will base their new project off of it and all the work we did to remove it is all for nothing.
Let the package die.
-Steve
On Thu, Mar 13, 2008 at 07:42:10AM -0400, Steve Grubb wrote:
What is different about this is that the package in question is crypto related. There are export restrictions and a lot of tracking associated with it. If you leave it in the distribution, eventually someone will base their new project off of it and all the work we did to remove it is all for nothing.
Let the package die.
I don't really understand the the export restriction issue. But 'all the work we did to remove it' should not bind packagers that don't have the same agenda.
-- Pat
On Thu, Mar 13, 2008 at 10:03 AM, Patrice Dumas pertusus@free.fr wrote:
On Thu, Mar 13, 2008 at 07:42:10AM -0400, Steve Grubb wrote:
What is different about this is that the package in question is crypto related. There are export restrictions and a lot of tracking associated with it. If you leave it in the distribution, eventually someone will base their new project off of it and all the work we did to remove it is all for nothing.
Let the package die.
I don't really understand the the export restriction issue. But 'all the work we did to remove it' should not bind packagers that don't have the same agenda.
Fedora as an entity of Red Hat is restricted by the rules and regulations of the United States. That includes certain export restrictions that require regular reporting and ok from US agencies in charge of Encryption. Similar regulations exist in other countries in Europe (France, Russia, and Germany I think, but those regulation may have gone away or not as enforced) and Asia. So every package that contains encryption has to be registered and gotten at least a token approval before it can be shipped, updated, etc.
On Thu, Mar 13, 2008 at 11:18:46AM -0600, Stephen John Smoogen wrote:
Fedora as an entity of Red Hat is restricted by the rules and regulations of the United States. That includes certain export restrictions that require regular reporting and ok from US agencies in charge of Encryption. Similar regulations exist in other countries in Europe (France, Russia, and Germany I think, but those regulation may have gone away or not as enforced) and Asia. So every package that contains encryption has to be registered and gotten at least a token approval before it can be shipped, updated, etc.
This is a fairly good reason not to ship it then. Maybe there could be a page somewhere in the wiki stating the state of affair, just like there is for licenses (and patents stuff). It should be part of the review to notice somebody in charge of registering it. Also the boundary of what is crypto should be defined somwhere. Are the code doing hashes (like md5 sums) crypto?
-- Pat
Patrice Dumas wrote:
On Thu, Mar 13, 2008 at 12:33:17AM -0500, Toshio Kuratomi wrote:
There's some basis for Jef's argument in the "Fedora is not a dumping ground for old, unmaintained software" philosophy. OTOH, the line between no upstream, a little upstream activity, and maintained by the Fedora Packager could get blurry here. So if we're planning on proposing some actual guidelines regarding what is an appropriate level of upstream activity to consider a package for Fedora, a conversation about this is *definitely* needed.
This comes up now and then. Some package are completly unmaintained, but also completly stable and don't need an upstream maintainer anymore, so that maintaining them in fedora is right.
This may be OK for some types of packages, but crypto has challeges of it's own. There are constantly new attacks published against existing crypto implementations. These attacks are not necessarily 'bugs' in the implementation, per se (not the same way a stack over flow or an uninitialized variable is a bug -- even it it's latent), but improvements in the state of the art of cryptanalysis). Any crypto code without a very active upstream tracking these issue will very quickly atrophie and become vulnerable.
bob
On Thu, Mar 13, 2008 at 10:24:31AM -0700, Robert Relyea wrote:
This may be OK for some types of packages, but crypto has challeges of it's own. There are constantly new attacks published against existing crypto implementations. These attacks are not necessarily 'bugs' in the implementation, per se (not the same way a stack over flow or an uninitialized variable is a bug -- even it it's latent), but improvements in the state of the art of cryptanalysis). Any crypto code without a very active upstream tracking these issue will very quickly atrophie and become vulnerable.
Network faced clients and servers have the same security issues. But this doesn't allow to make oen for all decision regarding maintaining or not this kind of packages in fedora. The maintainer may be skilled enough and have enough time to substitute for the upstream. We cannot say it in advance, and should leave it to the maintainer.
(The export stuff is another issue, a legal issue).
-- Pat
On Thu, Mar 13, 2008 at 9:30 AM, Patrice Dumas pertusus@free.fr wrote:
Network faced clients and servers have the same security issues. But this doesn't allow to make oen for all decision regarding maintaining or not this kind of packages in fedora. The maintainer may be skilled enough and have enough time to substitute for the upstream. We cannot say it in advance, and should leave it to the maintainer.
Then I would humbly suggest that maintainers who feel than can take up that burden establish themselves as an upstream developer for a project (or a fork). I am loathe to see Fedora package maintainers attempt to do the work of maintaining an otherwise dead library codebase inside the Fedora packaging space. This should be avoided. If a package maintainer can re-establish an upstream development process that is not run out of the fedora package cvs....then fine.
Though in this specific case, its not clear that beecrypt is actually a dead codebase. There's no evidence of it shutting down. sf.net shows at least one cvs write transaction in the last couple of months, and several with in the last 12 months. And it appears the main developer has responded to a mailinglist thread from 2008. Though there are patchsets sitting in the ticket que since last summer. That's not an good sign, especially if this needs patching to build with the new gcc.
-jef
On Tue, 2008-03-11 at 16:37 -0400, Steve Grubb wrote:
On Tuesday 11 March 2008 03:48:43 pm Robert Scheck wrote:
I've a third party application which depends on beecrypt, so I would claim the ownership of this package at least on devel (maybe co-maintain on other branches).
I'd suggest they port to another library or package beecrypt into their application. We need to stop the proliferation of crypto and try to get it down to 1 or 2 libraries if at all possible.
There's no point in discussing this. It is not backed by any guideline that is currently in effect.
And yes, it would be nice if we had just one crypto library, but having it in repo doesn't mean anyone would use it. It just mean it would make life of some people easier; Robert's for example. That is why limiting plurality is not backed by a rule.
On Tue, Mar 11, 2008 at 10:30:45PM +0100, Lubomir Kundrak wrote:
And yes, it would be nice if we had just one crypto library, but having it in repo doesn't mean anyone would use it. It just mean it would make life of some people easier; Robert's for example. That is why limiting plurality is not backed by a rule.
Actually the reverse is the rule. Any free software application can enter fedora.
-- Pat
devel@lists.stg.fedoraproject.org
-
Callum Lerwick -
Jef Spaleta -
Jos Vos -
Lubomir Kundrak -
Patrice Dumas -
Robert Relyea -
Robert Scheck -
Stephen John Smoogen -
Steve Grubb -
Tomas Mraz -
Toshio Kuratomi