On 04/05/2015 03:25 PM, Rich Freeman wrote: > On Sun, Apr 5, 2015 at 8:23 AM, Diego Elio Pettenò > <flamee...@flameeyes.eu> wrote: >> >> Since as you point out the two packages are vastly API compatible, it makes >> them ABI incompatible and conflicting. > > ++ > > If they really want to improve the security of function calls that > they consider inherently secure, they should just introduce new > functions and deprecate the old ones, or make old ones wrappers around > new ones if that is appropriate. If they go with the deprecation > route then they need to avoid using the same SONAMEs, and if they go > the wrapper route they need to make sure that they're compatible > across SONAMEs. Of course, any re-implementation could have bugs, but > the key is that upstream has to recognize these incompatibilities as > being valid bugs that they intend to fix. Right now if something > designed to link against openssl breaks against libressl there is a > good chance that libressl will just say it is intentional, which then > leaves us in the position of having to deal with the mess. > > I agree that renaming things isn't a great solution either, and that > this really needs to be fixed upstream. However, I don't really like > it going into the tree the way it is, because sooner or later we're > going to end up with blockers or bugs. Either you can't install foo > with barssl, or you can, and it just might break but nobody really > keeps track of that. > > It really doesn't matter which is the better implementation - this is > just a really messy way to do a transition. >
You are ranting at the wrong place. If you want to make a difference, take this to the openbsd mailing lists.
