Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide debian/ubuntu packages with at least SHA256 digests for it's signature. #1110

Closed
disturbio opened this issue Mar 24, 2016 · 14 comments
Closed

Comments

@disturbio
Copy link

Hi,

Debian1 and Ubuntu2 are deprecating SHA1 from APT, this breaks the packages provided by packagecloud.io, as you will get this type of error running apt-get update:

W: gpgv:/var/lib/apt/lists/packagecloud.io_github_git-lfs_debian_dists_stretch_InRelease: The repository is insufficiently signed by key F86AA916A2195E121AEDB11437BBEE3F7AD95B3F (weak digest)

This change will affect ubuntu's next month stable release

Thanks in advance.

@technoweenie
Copy link
Contributor

@andyneff Is this something we can do on our end, or does something have to be done on packagecloud? Also, would it be worth updating existing packages, or just releasing LFS v1.2 before the next ubuntu stable release?

@javabrett
Copy link
Contributor

@bruo do you have any further details on the specific shortcoming?

I don't know that the git-lfs team directly signs any packages (don't think so, but they can confirm), but packagecloud do sign the repo metadata.

curl -LO https://packagecloud.io/github/git-lfs/debian/dists/jessie/Release
curl -LO https://packagecloud.io/github/git-lfs/debian/dists/jessie/Release.gpg
curl -Ls https://packagecloud.io/gpg.key | gpg --import

... then:

$ gpg --verify -v Release.gpg Release
gpg: armour header: Version: GnuPG v1.4.11 (GNU/Linux)
gpg: Signature made Fri 18 Mar 2016 19:18:42 AEDT using RSA key ID 7AD95B3F
gpg: using subkey 7AD95B3F instead of primary key D59097AB
gpg: using PGP trust model
gpg: Good signature from "packagecloud ops (production key) <ops@packagecloud.io>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 418A 7F2F B0E1 E6E7 EABF  6FE8 C2E7 3424 D590 97AB
     Subkey fingerprint: F86A A916 A219 5E12 1AED  B114 37BB EE3F 7AD9 5B3F
gpg: binary signature, digest algorithm SHA1

Note the digest algoritm is SHA1. That's likely the problem. When packagecloud sign the repo metadata they probably need to start passing --digest-algo SHA256 (or better) to gpg.

I've sent them an email to check.

See also:

@ice799
Copy link

ice799 commented Mar 29, 2016

Hi - I work on packagecloud. Thanks for reporting this to us via our support email. We're looking into this now.

Just a few notes I wanted to make about this from the packagecloud side:

  1. Regarding the emails linked in (Provide debian/ubuntu packages with at least SHA256 digests for it's signature. #1110 (comment)) our Release/InRelease and Packages files provide SHA256 and SHA512 signatures, so we should be good to go in that regard.
  2. We're going to attempt to verify which versions of Ubuntu/Debian can process GPG signed metadata with SHA256 digests -- we don't want to break anything for users on older systems. Once we figure that out, we can enable SHA256 digests for our GPG signatures on the right systems (which might be all of them).

We use ruby-gpgme for generating GPG signatures, so a fix might require a PR to that project -- we're still investigating.

I'll update this PR when I know more.

@disturbio
Copy link
Author

@javabrett debian wiki got update these days to know what is happening, you can read here https://wiki.debian.org/Teams/Apt/Sha1Removal. I don't use ubuntu, i don't know what's the status on their side.

@ice799 the issue is the digest one, your repository is "half broken". AFAIK there are no issues with any stable distribution with SHA512 digests, i've been using that in my gnupg setup since several years already.

@ice799
Copy link

ice799 commented Mar 29, 2016

@bruo Unfortunately, there are a lot of bugs with APT and how it uses GPG so we'll need to be extra careful here, but thanks for letting us know that it has been working for you!

@javabrett
Copy link
Contributor

@ice799

We use ruby-gpgme for generating GPG signatures, so a fix might require a PR to that project -- we're still investigating.

The only way I know of to make ruby-gpgme create signatures with the desired digest hash algorithm is to configure the local libgpgme and libgcrypt via the signing-user's ~/.gnupg/gpg.conf. There doesn't appear to be an API interface for this, which is weird, or at least I couldn't spot it. GPGME has the ability to return multiple digest signatures with identifiable type, but I don't know how you ask it for multiples or a specific one outside of GPG config.

$ tee -a ~/.gnupg/gpg.conf <<EOF
personal-digest-preferences SHA256
EOF

ruby-gpgme should then create SHA256 digests.

@ice799
Copy link

ice799 commented Mar 30, 2016

@javabrett yes, GPGME does not support setting the digest algorithm. There's a few technical reasons why we cannot simply set a gpg config on our side. We're still working through the best way for us to solve this and we appreciate your input. I think it's likely that I'm going to write a small patch for libgpgme and ruby-gpgme to allow setting the digest.

@ice799
Copy link

ice799 commented Mar 31, 2016

An update: I wrote a fix that is being code reviewed and tested. I'll follow up when a fix is deployed.

@technoweenie
Copy link
Contributor

I don't know that the git-lfs team directly signs any packages (don't think so, but they can confirm), but packagecloud do sign the repo metadata.

Our docker files used to sign them when they generated a full repo. I didn't want to deal with hosting it, so I decided to go with PackageCloud.

@ice799 Thanks for taking care of this. Is there anything we have to do on our end?

@javabrett
Copy link
Contributor

@technoweenie That confirms that git-lfs no longer performs any artifact or repo-signing, so this issue is purely related to signing provided by packagecloud. @ice799 if you have a public tracker for that we could probably close this issue.

@ice799
Copy link

ice799 commented Apr 1, 2016

@technoweenie The initial error message reported was about the GPG signatures on the repository metadata (which are generated by packagecloud). There is nothing on your end to be done -- we're working on a fix on our side for this.

Keep in mind that packages themselves can also be GPG signed. If you want to sign them, you'd have to do this before uploading them to packagecloud. It's likely not worth signing them at this time because of the pain involved with actually enabling verification on the client side. Almost no one is going to do it.

If you are curious about GPG signing packages vs GPG signing APT metadata, check out this helpful blog post which explains the difference and the meaning behind each.

@javabrett sorry, we do not currently have a public issue tracker, but I suspect a fix will be deployed early next week.

@ice799
Copy link

ice799 commented Apr 2, 2016

OK, we pushed a fix for this and reindex this repository. Repository metadata should be GPG signed with a signature that uses SHA256 for most recent Ubuntu and Debian releases.

@bruo you should not get this error now, however, please note that git-lfs has no packages that have been uploaded for debian/stretch - so if you try to apt-get install you will get package not found. you will need to either ask @technoweenie to upload packages for debian/stretch OR install the packages for debian/jessie instead.

@disturbio
Copy link
Author

@ice799 yeah, i just notice that. anyway, that will be a different issue and the problem is fixed. (you will get the same request probably from slack people, as it was a reported issue by the debian's "sha1 deprecation team"

Thanks to all of you for you work.

@javabrett
Copy link
Contributor

@ice799 Thanks, looks good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants