# Devuan meet 2022-09-22 @20:30 UTC

Present: hendrik, golinux, fsmithred, bb|hcb, rrq Regrets: plasma41

## Old Business

## Old Actions

## New Business

### LeePen

#### init-system-helpers and usrmerge Debian's version 1.65.2 forces
usrmerge migration. Until this plays out I have reverted this change
in our fork. However, once usrmerged paths become compiled into the
binaries we inherit, we may have to follow. Unless anybody has
alternative suggestions? (bb|hcb) I am watching usrmerge since long
ago and do not see an easy way to avoid it. The challenge is to find
to proper timing to follow the usrmerge and minimize the damage to
Devuan users. (rrq) well, not sure I see the necessity, but not too
fussed. As long as files are installed at paths not starting with /usr
it'll be easy to make a "bad" reference to them; one that is broken
without "usrmerge". In my view there is no technical merit. Not sure
I'll be on those barricades though.

#### Keyring Reworked packaging for devuan-keyring. Built version
  2022.09.22 for experimental. Includes new Release signing keys for
  Daedalus, Excalibur and a generic key for Amprolla as a spare. Also
  individual keys for LeePen, rrq (✕2), bb|hcb and fsmithred. Does
  anybody else want their key adding?
  * (plasma41) I will want mine added eventually, but I'm still working
    on making one and am honestly probably going about it in a manner
    that is far too pedantic.
  * (rrq) we should add an "instructtions document" to the project about
    the management of developer and archive keys.

#### Other Packaging Updated sysvinit, debian-installer (mini.isos)

#### Amprolla Changed archive.devuan.org instance to use 2016 Release
signing key.

### bb|hcb

#### Thoughts on key management
* authoritative source of Devuan keys is `devuan-keyring` git repo
* involving keyring and/or bunch of keyservers in the process can't hurt
(the key list is managed centrally and updating from keyservers can
only add more signatures, which is good)
* keyring/keyservers are just a convenience to automate updating the
signatures (`gpg --no-default-keyring --keyring xxx --refresh-keys`)
* process of adding a new key to devuan-keyring: best done via PR in git
* shall we run `keyring.devuan.org` - it can automatically merge keys
and signatures from the repo and before building `devuan-keyring` the
additional signatures will be merged back in the repo; this also
becomes a public authoritative source for the keys
* it is a good practice to sign the new Devuan keys with the old ones

#### TODO for devuan-keyring
* add a helper script to update the existing keys with new signatures
from keyservers and/or keyring (no problem to do both); that should be
a manual step before building the package
* sign the Devuan distribution keys by the developers

#### Process of signing another person's key
* fetch the key to sign, preferrably by long id, e.g.
BA60BC20F37E59444D6D25001365720913D2F22D: ```` gpg --recv-key
BA60BC20F37E59444D6D25001365720913D2F22D ````
* verify that the person matches the key via a separate channel and the
fingerprint of the key
* it is also good to verify that the key algorithm and bits match
* do not sign keys of persons whom you haven't verified
* sign the key and encrypt the result to the person ```` gpg --sign-key
BA60BC20F37E59444D6D25001365720913D2F22D` gpg --armor --export \
BA60BC20F37E59444D6D25001365720913D2F22D | \ gpg --armor --sign
--encrypt --recipient \ BA60BC20F37E59444D6D25001365720913D2F22D \ >
BA60BC20F37E59444D6D25001365720913D2F22D.asc.pgp ````
* do not send the signed key directly to keyservers
* send the encrypted result from above by email to the address from the
key
* the person who's key was signed will decrypt, import and publish the
new signature: ```` gpg --decrypt
BA60BC20F37E59444D6D25001365720913D2F22D.asc.pgp gpg --import
BA60BC20F37E59444D6D25001365720913D2F22D.asc gpg --keyserver
keyring.devuan.org --send-keys
BA60BC20F37E59444D6D25001365720913D2F22D gpg --keyserver
keyserver.ubuntu.com --send-keys
BA60BC20F37E59444D6D25001365720913D2F22D ````

#### Process of signing a Devuan release key
* fetch the key to sign, preferrably by long id, e.g.
72E3CB773315DFA2E464743D94532124541922FB: ```` gpg --keyserver-options
no-self-sigs-only --recv-key 72E3CB773315DFA2E464743D94532124541922FB
````
* verify that this is the actual Devuan's key by different channels
* compare the algorithm and bits
* check if the key is already signed by others you already trust ````
gpg --check-sig 72E3CB773315DFA2E464743D94532124541922FB ````
* sign the key and encrypt the result with the key itself ```` gpg
--sign-key 72E3CB773315DFA2E464743D94532124541922FB` gpg --armor
--export \ 72E3CB773315DFA2E464743D94532124541922FB | \ gpg --armor
--sign --encrypt --recipient \
72E3CB773315DFA2E464743D94532124541922FB \ >
72E3CB773315DFA2E464743D94532124541922FB.asc.pgp ````
* do not send the signed key directly to keyservers
* send the result by email to the address from the key (does
repository@??? work?)

## New Actions (gl) Equinox greetings to all!! (hendrik) Greetings
appreciated.