[pacman-dev] [PATCH 2/3] Use OpenSSL MD5 crypto functions if available

[Dan McGee]

On Mon, Sep 6, 2010 at 9:34 AM, Allan McRae <allan at archlinux.org> wrote:
> On 05/09/10 22:10, Allan McRae wrote:
>>
>> On 04/09/10 19:16, Jürgen Hötzel wrote:
>>>
>>> Hi Dan,
>>>
>>> 2010/9/2 Dan McGee<dan at archlinux.org>:
>>>>
>>>> This does not remove the MD5 code from our codebase, but it does enable
>>>> linking against OpenSSL to get their much faster implementation if it is
>>>> available on whatever platform you are using. At configure-time, we will
>>>> default to using it if it is available, but this can be easily
>>>> changed by
>>>> using the `--with-openssl` or `--without-openssl` arguments to
>>>> configure.
>>>
>>> What about just replacing the current MD5 implementation with the
>>> OpenSSL implementation?
>>>
>>> This would prevent conditional compilation and a direct OpenSSL
>>> dependency in libalpm.
>>
>> Can we do that? Openssl is BSD code.
>>
>>
>> Anyway, I have concerns... Think of an openssl upgrade. pacman is in
>> SyncFirst and it pulls in all its deps. If that pulls in openssl with a
>> soname bump, things may get interesting. I have not check, but I do not
>> think --as-needed saves us there.
>>
>
> My concern is lessened...   I just did an update on a year old install and
> pacman pulled in openssl for the lib* updates.  I did another update and
> nothing too bad happened.  So this may be fine.

We already had this non-explicit dep chain anyway: pacman ->
libarchive -> openssl, or pacman -> libfetch -> openssl. Moving it up
one level shouldn't affect a whole lot.

The only thing that should break here is "everything else" on your
system. E.g. if you are prompted to upgrade pacman first because it is
in SyncFirst, and it pulls in an so-bump OpenSSL, then anything else
on your system that links that library won't work until you complete a
full -Syu. However, as I pointed out above, this was already happening
as far as I can see before.

-Dan