3 ms·

Looks really interesting! I may be about to show my apt inexperience here, but I don't see any explicit callout of a signing step. Does apt handle signing only

by akerl_ 10y ago

Looks really interesting! I may be about to show my apt inexperience here, but I don't see any explicit callout of a signing step. Does apt handle signing only at the package level, such that you'd just sign when you build a single package and then upload that? I've written a tool for managing Archlinux repos in S3 ( https://github.com/amylum/s3repo https://github.com/amylum/s3repo ), which I run in a container myself so that I can use my GPG key to sign the packages and the full repo metadata. I'd love to move to something like this, so I'd be able to let AWS handle running the lambda on my behalf, but I've yet to figure out a good way to do that with the signing structure necessary

leetrout 10y ago
Not OP but I left another comment further up- I also run my Yum & Apt repo builds in containers and I have lambda launch those containers when S3 is updated... In order to facilitate signing I have my GPG key on the container host machine and mount that directory as a volume in the container so the container has access to the key as well. For initially provisioning the container server I deploy the GPG key as an encrypted blob and decrypt it on the host.
- akerl_ 10y ago
  Yup yup. I do similarly at the moment. I was brainstorming a bit more, I think if I were to port to Lambda, I'd probably use a KMS-encrypted S3 object to store the private key. That said, it would mean fixing up my original key strategy. At the moment, I'm using a signing subkey of my personal GPG key, since it's just a personal repo and I control the VM/container where the stuff happens. By comparison, if I were dropping it into a lambda/s3, I'd probably be more motivated to split onto a fully separate key for the repo.
szinck 10y ago
Yeah you just sign the packages. There is an option to create a signed "Release" file, but I'm not creating a "Release" file. "Packages" is the only one I'm creating for now. If you wanted to create a signed release file or other files, you could just add that after the step that creates Packages.

by akerl_ 10y ago

leetrout 10y ago

Not OP but I left another comment further up- I also run my Yum & Apt repo builds in containers and I have lambda launch those containers when S3 is updated... In order to facilitate signing I have my GPG key on the container host machine and mount that directory as a volume in the container so the container has access to the key as well. For initially provisioning the container server I deploy the GPG key as an encrypted blob and decrypt it on the host.

akerl_ 10y ago
Yup yup. I do similarly at the moment. I was brainstorming a bit more, I think if I were to port to Lambda, I'd probably use a KMS-encrypted S3 object to store the private key. That said, it would mean fixing up my original key strategy. At the moment, I'm using a signing subkey of my personal GPG key, since it's just a personal repo and I control the VM/container where the stuff happens. By comparison, if I were dropping it into a lambda/s3, I'd probably be more motivated to split onto a fully separate key for the repo.

szinck 10y ago

Yeah you just sign the packages. There is an option to create a signed "Release" file, but I'm not creating a "Release" file. "Packages" is the only one I'm creating for now. If you wanted to create a signed release file or other files, you could just add that after the step that creates Packages.