[Top][All Lists]

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

Re: [task #4633] GPG-Signed Commits

From: Mark D. Baushke
Subject: Re: [task #4633] GPG-Signed Commits
Date: Mon, 19 Sep 2005 10:09:03 -0700

Hash: SHA1

Derek Price <derek@ximbiot.com> writes:

> One more thought on planning this feature, this is
> important enough to go into the stable release series, I
> think, but we are awfully close to being able to bless
> feature as stable anyhow.

Hmmm... I think we are fairly close, but I suspect the
gpg-signed feature may take a lot of work to get correct...

> Would there be any objections to GPG-signed commits going
> into stable as things stand?

I tend to agree with Jim Hyslop's comments regarding getting
some field trials in place and ensuring that it is bug-free
before considering back-porting it to 1.11.x...

I think it would be faster to push 1.12.x into being a
'stable' release...

> Would there be any objections to 1.12.x being blessed as
> stable after adding GPG-signed commits, importing an
> updated diffutils, possibly completing the commitid stuff,
> and maybe an RC release or two?

I have no real objection. I think it is reasonable to list
the stuff that folks have submitted to the lists or the old
www.cvshome.org issuetracker that may wish to be considered
for 1.12.x before it becomes 'stable'.

The following may not be a complete 'wish list', so if I
have missed anything, feel free to add here for

  - 'cvs import' goes through a pre-import trigger (be it a
    new trigger or be it a combination of commitinfo and

  - Updated diffutils.

  - The Frank Hemer <frank@hemer.org> newtags feature.

  - A change to 'cvs add', either it goes through a
    commitinfo trigger for new directories (it also needs to
    get a CVS/Template populated when it is created which
    seems to be a minor bug), or going with Greg A Woods
    <woods@weird.com> suggestion to defer the connection to
    the server until the 'cvs commit' has been issued (ie,
    make cvs add client/server semantics like cvs rm
    symmetric). The thread is here:
    There is a long-standing issue here:

  - GPG-signed feature.

    + This means some way to have the server manage GPG key
      material in some kind of a cvs server 'web-of-trust'.

    + There is a need to deal with expired keys and revoked
      keys as well as with successor keys.

    + There may need to be a new way for a client to obtain
      the public keys related to all files in the repository
      as a part of a 'verify' operation... would this imply
      running an hkp: or ldap: server on the cvs host, or
      would cvs have additional client/server protocol put
      in place to handle this?

    + Client-side user-requested 'diff' replacement (to
      allow validation of all versions related to a 'diff'
      as well as to provide a replacement of 'diff' with
      graphical or special-purpose comparisons (e.g., binary
      difference engines or xml difference engines).

    + Client-side user-requested 'diff3' replacement (to
      allow validation of all versiosn related to a 'merge'
      operation as well as to provide a replacement 'diff3'
      with a graphical or special-puposes merge operation
      (e.g., allow a special-purpose program to merge
      graphics or other 'binary' files).

  - cvs output should be able to support xml to allow
    projects like cvslib and other cvs clients to more
    effectively communicate with the server.

  - Per recent discussions on Unicode, the possibility of a
    new feature that is orthogonal to keyword expansion that
    controls if line endings conversion should take place or
    not. (This may be desirable for GPG-signed form in any

  - Desire the ability to deal with execute bits between
    'cvs rm' and a new 'cvs add' of the same filename.
    Possibly a new admin command to change the execute bits
    on the repository file?

  - Some folks desire a way for 'cvs import' and possibly
    'cvs add' to have a method to determine keyword
    substitution for new files

  - Some folks desire an option to 'cvs update' to make the
    time of the updated file be the commit timestamp rather
    than the update timestamp.

  - As a robustness, when LockDir is not being used, it may
    be desirable to prohibit directories that look like cvs
    internal lock files.

CVSNT 'features' that I have heard mentioned might be
'useful' to port back to CVS are:

  - the 'mergepoint' feature 

  - the 'LockServer' (faster and more granular locks) feature

  - the 'access control lists' feature

  - pluggable server-side diff programs (I do not believe
    that pluggable server-side diff programs are going to be
    useful if the GPG-signed feature is enabled).

I think that about covers the features I recall being
requested... I am not saying that they all need to go into
1.12.x before it becomes stable, just that they should be
addressed in some way to set expectations before 1.12.x goes
to the first release candidate.

        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

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