Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git files hidden in plain sight

tylercipriani.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Git files hidden in plain sight

#21

Post by upofadown »

whirlwin wrote: post #7
seeknotfind wrote: post #3

Earlier quoted context omitted.

This is not a security issue. The key is just hard to update when it expires. Private is private, public is public, even in git.

Why does it need to be public? By revealing your public key you also reveal the algo used for your public/private keypair. If you are a renowned developer and have an insecure algo, you might be a victim for targeted attacks

>If you are a renowned developer and have an insecure algo, ...

Example of such an insecure algorithm that might be relevant here?

Re: Git files hidden in plain sight

#22

Post by woodruffw »

whirlwin wrote: post #13
woodruffw wrote: post #9

Earlier quoted context omitted.

If your goal is to have others verify your signatures, then they need to have your public key. The solution to using weak algorithms is to not use them, not to hide your public key. If you don’t reveal your public key, then there’s effectively no value in the signatures made by its private half.

Isn't the best way to verify the integrity to use git signed commits? GitHub has great support for this

You’re mixing up integrity and authenticity: git provides integrity through its basic design; commit signing additionally adds authenticity (sort of).

But again: you don’t actually get authenticity if you obtain the public key from the same untrusted channel as the signed material. The key has to come from another channel (another simplification, but true in PGP and git’s case). That channel can be the user’s GitHub profile, website, etc., but it can’t be the repository itself.

Re: Git files hidden in plain sight

#23

Post by upofadown »

The first example involved a signing key that expired. What would be the point of expiring a signing key? What would that mean? In a paper context, a signature or seal is still considered valid even if the technical means to create such marks no longer exists. Even if you lose your pen or stamp, signatures made with the pen or stamp are still binding.

Implementations should probably just ignore the expiry of a key used for signing when checking a signature...

Re: Git files hidden in plain sight

#25

Post by layer8 »

upofadown wrote: post #23

The first example involved a signing key that expired. What would be the point of expiring a signing key? What would that mean? In a paper context, a signature or seal is still considered valid even if the technical means to create such marks no longer exists. Even if you lose your pen or stamp, signatures made with the pen or stamp are still binding. Implementations should probably just ignore the expiry of a key us…

For long-term signatures, the designated way to handle this is using cryptographic timestamps that establish when the signature was created. That proof-of-existence time is then compared to the validity period of the certificate associated with the key. This allows successfully validating signatures even after certificate expiration.

Certificates have an expiration date because keys can be compromised, and cryptographic algorithms can become weak and be broken. The expiration date imposes a time limit for possible fraudulent use of the key.

When using certificates, it’s also the certificate that expires, not the key. A new certificate for the same key can be issued (certificate renewal).

Re: Git files hidden in plain sight

#26

Post by jagged-chisel »

upofadown wrote: post #23

The first example involved a signing key that expired. What would be the point of expiring a signing key? What would that mean? In a paper context, a signature or seal is still considered valid even if the technical means to create such marks no longer exists. Even if you lose your pen or stamp, signatures made with the pen or stamp are still binding. Implementations should probably just ignore the expiry of a key us…

If the signature creation date is before the key expiration date, the signature is valid. If the signature creation date is after expiration, it is possible (more likely than before) that someone else discovered the private key and has signed the document.

Signing key expiration exists for the same reason certificate expiration exists: we create keys that are infeasible to discover with current methods, and create replacements as techniques advance. This encourages us to create stronger keys over time.

Had you failed to notice a key expiration from the 80s, you would assume the signature is valid - but most computing devices these days could have just generated the signature without the original key.

Re: Git files hidden in plain sight

#27

Post by nebulous1 »

talkingtab wrote: post #24

Is this a git issue or a github issue? I know git is being (mis)used, but the issues seem to be with github. Maybe a better title for those of us with no interest in github would be "Github hides git files in plain sight" ?

I think there is no issue. But, yes, it seems like if there is one then it's with the github UI.

Re: Git files hidden in plain sight

#28

Post by upofadown »

jagged-chisel wrote: post #26
upofadown wrote: post #23

The first example involved a signing key that expired. What would be the point of expiring a signing key? What would that mean? In a paper context, a signature or seal is still considered valid even if the technical means to create such marks no longer exists. Even if you lose your pen or stamp, signatures made with the pen or stamp are still binding. Implementations should probably just ignore the expiry of a key us…

If the signature creation date is before the key expiration date, the signature is valid. If the signature creation date is after expiration, it is possible (more likely than before) that someone else discovered the private key and has signed the document. Signing key expiration exists for the same reason certificate expiration exists: we create keys that are infeasible to discover with current methods, and create re…

Why would an attacker with access to the private key specify a signature creation date after key expiry? They can specify whatever date they want.

>Had you failed to notice a key expiration from the 80s, you would assume the signature is valid ...

If the algorithm is broken then the implementation should not support verification using that algorithm no matter the expiration date. An attacker can update the key's expiration date to whatever they want if the algorithm is broken.

Re: Git files hidden in plain sight

#29

Post by jrms »

woodruffw wrote: post #11
seeknotfind wrote: post #3

Earlier quoted context omitted.

This is not a security issue. The key is just hard to update when it expires. Private is private, public is public, even in git.

It’s a security issue in the sense that it defeats the signing scheme: rather than negotiating the key out-of-band, the user is trusting the thing they’re trying to verify to supply the key. In other words “trust me because I’m signed, and also trust me to give you the key I’m signed with.” On the other hand, approximately nobody actually verifies git commit signatures, so it doesn’t matter all that much :-)

I do. Deploys can only be rolled out if the tag was signed by a well known list of people (git pull --verify-signatures).
Post reply on HN