On Thu, Mar 22, 2012 at 02:28:43PM -0300, Denis A. Altoé Falqueto wrote:
That's an interesting situation. If I understood you correctly, you have something like:
repository box: Downloads some updates that you'll test and approve. After that, you'll publush a new version of your repository database.
other boxes: Updates from your private repository. Do they update only from your repository or can they eventually get updates from Arch? I presume they update only from your repository.
This is entirely correct and the intended setup. I want/need to switch from rolling release to a tested "stable" repository for my clients, to ensure a smooth update experience. Basically the kind of setup that's advertised to those who bemoaned the lack of a stable repository in Arch in the past. ;)
What you maybe don't know is that pacman don't use those .sig files to really check the packages. The signatures come with each repository database, in the metadata for each signed package. So, you shouldn't really have to download them again, you already got them with Arch's database repositories, in your repository box.
Indeed, I didn't know that, thank you (and Thomas!) very much. That'll do just nicely!
I would do the following:
1. Create a gpg key on the repository box 2. Sign the database you create with repo-add (you can choose the key to use) 3. On the other boxes, use pacman-key to import and trust your repository public key 4. Update your other boxes 5. Be happy :)
That's precisely what I did. :) I just didn't realize until now that the trust chain is kept intact by simply signing my local repo database with my internally trusted key created on the repository box, but it all makes sense now. In fact that's even better than I hoped, as this procedure allows the clients to ONLY trust my repository box key and won't have to bother with importing any other keys and a complex web of trust, even when AUR or homebrewn packages need to be integrated.
For future updates of your repository, you'll have to re-sign it. What you really get is a two level trust system. Your repository box trusts Arch's keys and your other boxes trust your repository key.
That's perfect for my purposes. I might switch to having multiple, internal repository keys with crossover revocation similar to the Arch master key concept, but so far I enjoy the RAW, UNLIMITED POWER of being fully trusted. ;)
Hope that helps.
Absolutely. Thanks to Thomas and Allan as well! It's great to see how far Arch has come during the last 10 years. It hasn't let my down since. I'll make sure to document my procedure of "snapshotting" the package state of a system along with my bash magic in the wiki. It's a bit more involved than what is already described in "Pacman Tips". Best regards, and keep up the great work! Dennis