Re: How to download .sigs into CacheDir with pacman

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux