bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [task #4633] GPG-Signed Commits


From: Sylvain Beucler
Subject: Re: [task #4633] GPG-Signed Commits
Date: Sat, 10 Sep 2005 00:40:05 +0200
User-agent: Mutt/1.5.9i

On Fri, Sep 09, 2005 at 05:12:23PM -0400, Derek Price wrote:
> Jim Hyslop wrote:
> 
> > Derek Robert Price wrote:
> >
> >>                  Summary: GPG-Signed Commits
> >> I put up an editable design document/RFC here:
> >> <http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits>.
> >>
> >> The most recent public thread on this topic is here:
> >> <http://lists.gnu.org/archive/html/info-cvs/2005-08/msg00221.html>.
> >
> >
> > One thing I didn't see in the discussion (maybe I missed it) is: why
> > is this feature desirable? What are the benefits of it? (I have some
> > ideas, but I'm going to play dumb here [smart remarks > /dev/null] :=)
> >
> 
> You were looking for more than: "CVS does not provide verification of
> past revisions of files. Attackers with access to a CVS repository could
> replace file contents or add new revisions apparently from a project
> member without users noticing on checkout." (from
> <http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits#Abstract>).
> 
> This whole discussion started a year or two ago, when both Savannah &
> cvshome.org were hacked at approximately the same time.  The idea is
> that there is a lot of source on these system in use in a lot of
> places.  Someone hacking root on the system, with access to the CVS
> repository, could potentially insert unnoticed backdoors in all sorts of
> software and have those changes quietly downloaded onto developers
> computers without anyone ever being the wiser.
> 
> Granted, part of the nature of open source is that hopefully someone
> would spot this sooner or later, but gpg-signed commits would hopefully
> bias that towards the sooner side.


Another "benefit" is that in the case of a new server compromise, and
if a CVS file is successfully altered, the person to blame is not the
server maintainer anymore (for not securing the server properly), but
rather the developer (for not securing his GPG keys properly).

Of course that's no excuse for poor security.

-- 
Sylvain




reply via email to

[Prev in Thread] Current Thread [Next in Thread]