|
Actions:
|
2011-05-10 07:51 AEST by Arthur Barrett - If people are using CVS from an iPad, iPhone, Nook or Kindle - what are they going to use it for?
We have one customer in AZ that is using CVS Suite primarily for documentation - and they do a lot of
'digital signing' using the Adobe Acrobat workflow.
It'd be great if CVS Suite Server had some native support for signing.
1.
When Acrobat signs a document, the actual document changes. I've no idea how the check the
signature - internally the actual PDF must be containerised? I suppose this is the same problem with a
Windows EXE or MSI being signed, each EXE can have multiple signatures - so it's not checking the
signature against the entire file, but a 'part' of the file.
If info on these containers (for PDF's) is public info we could (optionally) store the PDF and the
signatures separately. Eg: the signatures in the 'properties' of the revision.
2.
If we could store signatures in the properties in a way that they still only apply to a revision if the
revision is unmodified (MD5) then that'd be good too.
3.
Signatures are not equivalent to promotion levels, eg: to promote form 'draft' to 'published' may require
two (2) signatures - and those can be in any order or possible two of three (author, reviewer,
supervisor). |
|
|
2011-05-10 08:36 AEST by Glen Starrett - A more general approach to signing may be useful too. The "author" keyword
currently contains a signature of sorts, but if there was a "code signing" type
of signature on a per-commit basis (e.g. like PGP signature at the bottom of an
email message, or a other digital sig wrapper on an email) then that could be
more generally useful to users of CVS Suite.
|
|
|
2015-03-11 12:41 AEST by Arthur Barrett - change subject from:
enh: signing - as in digital signatures
to:
enh: signing - as in digital signatures stored as revision property
Git uses SHA 'signatures' as the 'revision numbers' - that way if revision 1.10@Arthur is identical to
revision 1.21@Glen then Git knows without doing any work.
CVS can always retrospectively calculate the signature of any revision (by checking out that revision) - but
an SHA signature on the revision property would create an 'easy' way for a client to compare if the local
code is different to the originally checked out code (especially if the SHA was then stored in
CVS/Entries.Extra or somewhere …). |
|
|
2015-06-29 17:21 AEST by Arthur Barrett - Created an attachment (id=2821)
Derek Price's spec/design
This is somewhat related to a similar task undertaken by Derek Price on CVS
1.12:
http://savannah.nongnu.org/task/index.php?4633
Derek added patches to 1.12 to GPG sign CVS commits. From memory I think this
was adopted/sponsored by GNU/savannah (see newsgroup post from Sylvain Beucler,
link below) but they then ended up switching to SVN anyway…
http://lists.gnu.org/archive/html/info-cvs/2005-08/msg00221.html
Here is Derek's original requirements design document:
https://web.archive.org/web/20060721025624/http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits
The conversations date back to 2005 or so, I remember talking to Derek in
person about this too and later having detailed discussions with Tony about it.
Again from memory, we didn't really like the idea, and certainly didn't see it
as more important than something like user defined revisions or failsafe
audit/logging, then Tony wanted to focus on the 2.6 (then later 3.1/EVS)
projects, but OpenGPG signing never made it into the spec for those.
In a later post (same thread) a critical point is made:
3) We need to sign more than the checksum,
else an attacker could put an old vulnerable version back to HEAD.
So we need to state different "assertions" about the code: the
checksum, the filename, the path, the revision, the date, the author,
the commit message. Maybe also the new commitid you mentioned.
With this the revision should be difficult to move around without
notice.
http://lists.gnu.org/archive/html/info-cvs/2005-08/msg00382.html
|
|
|
2015-06-29 17:32 AEST by Arthur Barrett - The world has moved on a bit, in terms of cryptographic hash checksums and digital signing. e.g.: see
this article:
http://www.theregister.co.uk/2015/06/26/bitcoin_unbloating_blockchain/
That article references this service which can create a " proof of existence for any document" thereby
"Demonstrating data ownership without revealing actual data. " and "Document timestamping. " and later
allowing any person to "Check for document integrity.":
http://www.proofofexistence.com/about
That service creates the 'hash' on the bitcoin blockchain by creating a small (fractional) bitcoin
transaction. The advantage of that is that the blockchain hash is created by a large network of computers
and stored distributed across the web.
The same could be argued for CVS and the hashing and distributed availability could be (finally?) an
argument for a cloud based service (though I think the argument is a bit thin).
Regardless, if we are going to implement signing of revisions, this is all stuff we should take into account.
Especially the ability to have a cryptographic signature that a customer can use to 'prove' they had a
document at a point in time without needing to reveal the contents of that document.
|
|
|
2015-06-29 17:33 AEST by Arthur Barrett - Created an attachment (id=2822)
cryptographic signing using bitcoin blockchain pt1
|
|
|
2015-06-29 17:33 AEST by Arthur Barrett - Created an attachment (id=2823)
cryptographic signing using bitcoin blockchain pt2
|
|
|
2015-06-29 17:33 AEST by Arthur Barrett - Created an attachment (id=2824)
cryptographic signing using bitcoin blockchain pt3
|
|
|
2015-06-29 17:46 AEST by Arthur Barrett - More discussion here:
http://lists.gnu.org/archive/html/bug-cvs/2005-10/msg00037.html
and here:
http://lists.gnupg.org/pipermail/gnupg-users/2005-October/027111.html
|
|
|
2015-06-29 17:58 AEST by Arthur Barrett - It appears that Derek did most of the work on the branch 'signed-commits3' with maybe some later work
on the branch 'signed-commits4' and then merged in around Mon Apr 24 18:50:27 2006 UTC:
http://cvs.savannah.gnu.org/viewvc/ccvs/src/verify.c?root=cvs&view=log
There was NEVER any official 1.12 release after Sep 2005, so these changes never made it into most users
hands AFAICT (and therefore the patches may not be as well tested/robust) as more widely released
patches…):
http://savannah.nongnu.org/forum/forum.php?forum_id=4046
|
|
|
2015-06-29 18:02 AEST by Arthur Barrett - Created an attachment (id=2825)
description of docproof SHA256 signing
|
|
|
2015-06-29 18:18 AEST by Arthur Barrett - " FIPS PUB 180-1 also encouraged adoption and use of SHA-1" and "Federal agencies should stop using
SHA-1 for...applications that require collision resistance as soon as practical, and must use the SHA-2
family of hash functions for these applications after 2010" (emphasis in original)
https://en.wikipedia.org/wiki/SHA-2
The intersection with FIPS makes this bug somewhat co-dependant with:
Bug 6325 client: :ssh: should support smartcard (FIPS-140 PIV)
Bug 6326 Win: client: :sserver:should support smartcard FIPS 140 PIV
Bug 6327 Win: client: :sspi:should support smartcard FIPS 140 PIV
|
|
|
2015-06-30 10:07 AEST by Arthur Barrett - Created an attachment (id=2826)
Adobe spec for digital signing
There are several items here that can easily be confused:
1. producing a cryptographic hash of the original file
2. producing a cryptographic hash of the file as received by the server
(basically that's -klo or -kb)
3. a public key for the 'person' performing the commit
4. digital signature is a combination of 1+3 and/or 2+3 ensures that content
was signed by that person
5. the time that 4 occurred
A valid digital signature gives a recipient reason to believe that the message
was created by a known sender, that the sender cannot deny having sent the
message (authentication and non-repudiation), and that the message was not
altered in transit (integrity).
https://en.wikipedia.org/wiki/Digital_signature
Furthermore this bug/enhancement seeks to replicate the ability for several
different people to sign a document over time, so it makes sense that this
signature is going to exist in a 'meta' block just like microsoft digital
signatures exist on an exe file - you can have several, but it doesn't change
the contents of the actual file/exe at all.
An advanced enhancement to that would be to then produce platform specific
signed checkouts. i.e.: you could 'sign' the 'commit' of an exe, then when you
check it out it is a 'signed exe'. There would be two ways of achieving this:
1. the client would need access to the private key (e.g.: via gpg on linux, or
keychain on mac, certificate store on windows)
2. the server could 'sign' the result using a 'cvsnt signing key'.
Producing 'native' signed files from a checkout of a signed CVSNT commit will
mean that even if that file is removed from the CVSNT environment, it still
maintains a way to 'check' that it is still unmodified.
We need a list of what files can be signed for each OS. Something like:
- linux, any - but the signature is 'separate' to the file - pretty useless for
our purposes because they may as well use the signature stored in CVS since it
is also 'separate'.
- windows. certainly EXE, MSI. Others are unknown.
- mac. packages are signed, as are 'apps'. Others are unknown.
- acrobat. cross platform it has its own "electronic signatures" and also
"digital id's"
http://www.pcworld.com/article/2035744/e-signatures-the-complete-guide-to-paperless-signing.html
|
|
|
2015-06-30 10:22 AEST by Arthur Barrett - Created an attachment (id=2827)
Acrobat 9.1 supplements to ISO 32000-1:2008 spec ver 1.7
PDF specs are available here:
http://www.adobe.com/devnet/pdf/pdf_reference.html
ISO PDF Spec 32000 for PDF version 1.7:
http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf
It is technically identical (same page and section numbers too) to the ISO one:
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=51502
Since it is 9MB it is too big to attach to the bug. Instead I've attached the
latest Adobe supplement to the spec for Acrobat 9.1. These supplement
documents describe Adobe’s extensions and implementation notes relative to the
ISO 32000-1:2008, Document management, Portable document format, PDF 1.7. Adobe
has submitted these extensions to ISO for inclusion into the next version of
the ISO 32000 specification and they have all been accepted for part 2 of ISO
32000.
|
|
|
2016-08-09 07:31 AEST by Arthur Barrett -
Perhaps the GPG/MD5 should also be stored in the audit database. The Audit DB can store the
revision information (which is where this would go), but that will mean the Audit DB gets much larger.
An alternative would be a 'special' table just for the GPG/MD5, which would grow more slowly than
the revision table. |
|
|
2020-10-12 02:39 AEST by Arthur Barrett - added wayback machine link to Derek's original spec/design. |
|
|
2021-04-05 21:32 AEST by Arthur Barrett - Someone hacked a commit to git.php.net - and their response is to enact digital signing.
https://www.theregister.com/2021/03/29/php_repository_infected/
Again, this is 1+3:
- the hash of the file that was committed
- a signature of who committed it
So this is kinda related to authentication - it's about proving that commit came from a trusted user.
Ultimately this attach was successful because a revision was created outside of authentication and access
control.
I'm concerned that signed hashes at this point put the onus on those checking out to check all revisions are
signed by acceptable committers. I think this is good documentation to have, but it's an unbearable burden
on those using the checkout to be forced to validate this.
Instead this could be used to reject commits (not a valid signature).
Except that assumes the change happened through the commit process and not through a server backdoor
(more likely in my opinion, at least with CVS if not Git too).
If your CVS or Git repository is compromised with invalid/substitute data, how does the client detect it on
checkout? With some level of accuracy and limited performance overhead? I'm thinking the audit trail
maybe? Maybe an option for 'secure checkout' which checks all signatures on checkout? But if you can
create a fake revision, can you add a fake authorised signature? Unless the list of authorised signatures for
'secure checkout' comes from the client and not the server?
|
|
|
2024-08-25 11:09 AEST by Arthur Barrett - rather than using bitcoin blockchain, an alternative (or more advanced version) may be to use 'smart
contracts' usually on Ethereum.
https://en.wikipedia.org/wiki/Smart_contract
"Similar to a transfer of value on a blockchain, deployment of a smart contract on a blockchain occurs by
sending a transaction from a wallet for the blockchain. The transaction includes the compiled code for the
smart contract as well as a special receiver address. That transaction must then be included in a block that is
added to the blockchain, at which point the smart contract's code will execute to establish the initial state of
the smart contract. Byzantine fault-tolerant algorithms secure the smart contract in a decentralized way from
attempts to tamper with it. Once a smart contract is deployed, it cannot be updated. Smart contracts on a
blockchain can store arbitrary state and execute arbitrary computations. End clients interact with a smart
contract through transactions. Such transactions with a smart contract can invoke other smart contracts.
These transactions might result in changing the state and sending coins from one smart contract to another
or from one account to another."
This would be really interesting when combining bugs/issues, code, build and test. Especially if there was
deep integration to log how many times the code successfully ran/failed to run. The smart contract could
determine payments for delivering code to the repository (that successfully builds, or builds and passes
tests), penalties for bugs (or bugs not meeting SLA/resolved in a certain timeframe), rewards for early
delivery, etc.
This would act as a 'smart signature' - not only is this code signed by this author, but this code meets these
contract specifications (passes these tests). |