[Mesa-dev] [PATCH] mesa: Add mesa SHA-1 functions

[Emil Velikov]

On 15/12/14 14:16, Francisco Jerez wrote:
> Emil Velikov <emil.l.velikov at gmail.com> writes:
> 
>> On 11/12/14 21:51, Carl Worth wrote:
>>> From: Kristian Høgsberg <krh at bitplanet.net>
>>>
>>> The upcoming shader cache uses the SHA-1 algorithm for cryptographic
>>> naming. These new mesa_sha1 functions are implemented with the nettle
>>> library.
>>> ---
>>>
>>> This patch is another in support of my upcoming shader-cache work. Thanks to
>>> Kritian for coding this piece.
>>>
>>> As currently written, this patch introduces a new dependency of Mesa on the
>>> Nettle library to implement SHA-1. I'm open to recommendations if people would prefer some other option.
>>>
>>> For example, the xserver can be configured to get a SHA-1 implementation from
>>> libmd, libc, CommonCrypto, CryptoAPI, libnettle, libgcrypt, libsha1, or
>>> openssl.
>>>
>>> I don't know if it's important to offer as many options as that, which is why
>>> I'm asking for opinions here.
>>>
>> Hi Carl,
>>
>> Can we try to avoid adding new dependencies to mesa unless absolutely
>> needed. Neither of the proprietary drivers does so presently, so it will
>> be nice to keep the trend.
>>
>> While currently the steam runtime does not include libnettle I can
>> envision one day that they will/might. Even with steam aside I think
>> that this might cause issues with gnome & others' sandboxing.
>>
>> Long story short - can we import a sha1 implementation from another
>> project ? It will save us the "libstdc++ style steam runtime" issues,
>> plus it will ease the question of what to do under Windows :)
>>
> 

Hi Francisco,

Mostly a repeat from IRC for anyone interested:

> I don't think the steam libstdc++ linking issue is a good argument
> against adding a new dynamic dependency,
If history has thought us anything (libudev, libgcc_s, libstdc++) having
any extra dependencies will likely cause problems.

> AFAICT that one's caused by the
> steam run-time being stupid trying to override the system
> libstdc++.so/libgcc_s.so with its own outdated versions even though the
> GCC C++ runtime has done a good job in the past at keeping binary
> compatibility across different releases with the same major number
> through library, symbol and namespace versioning.
> 
If they are doing something stupid, let us be the smarter one, and work
things in such a way that despite how stupid it is it just works. I have
mentioned three solutions below, yet there may be more.

> I'm OK with adding a dependency on libnettle, and I think that dynamic
> linking is preferrable to static linking if the library we end up
> depending on follows reasonable versioning practices.
> 
Pick any library/project as you wish but consider the following:

 - Roll our own sha1/md5/etc. as already mentioned by OG and NR.  Crypto
security is not needed here but only a nice collision %.

 - Import the sources of project X. Sync it once every Y months and
revert to the old as a contingency plan (be that a bug/problems updating
etc.)

 - Provide a way to static link against library X, and if you insist a
dynamic one.


But before anything - put yourself in the shoes of the average linux
user nowadays. I.e. eradicate some 80% of your knowledge. Now try to run
steam (or any binary game/program) that ships its own libgcc_s/libstdc++.


Cheers,
Emil