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