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