>>>>> On Sat, 20 Sep 2014, hasufell  wrote:

>>> This is a bug in git. Do you want us to wait until it is resolved?
>>
>> Not a bug. There are VCSs (like Subversion or Bazaar) that use simple
>> revision numbers to identify their commits. Git happens to use a hash,
>> which is perfectly fine as long as accidental collisions are unlikely.
>> Neither has to do anything with security, though.

> Because there are other VCSs it is not a bug??

No, but with any other VCS we wouldn't have this discussion. Git using
SHA-1 obscures the fact that an additional security layer is needed.
This can be either a secure channel for accessing the repository
(developers pushing their commits to it), or signed Manifests that
ensure integrity of the tree distributed to users.

> Of course it is a bug since it is in the gpg-signing chain and to
> use it in a practical way is very unlikely.

> So you are suggesting to not migrate at all or severely break the
> workflow because someone might forge _working code_ with a specific
> SHA1? There is no efficient algorithm for that afaik, those are just
> about finding _any_ collision and even then it takes considerable
> resources that can be used to break gentoo in much easier ways.

Weakness of SHA-1 is discussed since several years, and it is
generally recommended that one should slowly move away from it.
Therefore I would find it strange if we (in 2014!) deployed a system
relying on it, while in our present Manifest files SHA-1 was already
abandoned long time ago, in favour of more secure hashes. It looks
like a move in the wrong direction.

Ulrich