:: [devuan-dev] Meeting notes 2022-09-…
Top Page
Delete this message
Reply to this message
Author: B Stack
Date:  
To: devuan developers internal list
Subject: [devuan-dev] Meeting notes 2022-09-15
# Devuan meet 2022-09-15 @20:30 UTC

Present: amesser, Plentyn, plasma41, Hendrik, golinux, fsmithred

## Old Business

## Old Actions

## New Business

### golinux
* Is a public explanation of the key renewal failure even needed at this
point? (LeePen) I don't think so. It risks inviting further comment.
(gl) Agreed. We really missed an opportunity there . . .
* The invitation for "wiki whisperers" seems to be going nowhere.
* Did anyone contact MiyoLinux about his offer to help monitor keys?
There was someone else also. I did preliminay contact but know nothing
about keys or monitoring them. Not good when volunteers are not
brought in to do something . . .

### LeePen

#### Packaging
* Updated sysvinit, pcsc-lite, debian-installer (mini.isos),
network-manager, pcsc-lite, udisks2, rsyslog (chimaera-backports)
* Dyne's arm builder was offline. Now online but connectivity seems
unreliable so temporarily disabled.

#### Amprolla
* Changed to sign with 2016 GPG key. Unfortunately it is only 2048 bits.
* Added support for signing suites with different keys. Initial patch
  from bb|hcb. Currently running on test instance.
  * (plasma41) Does that mean signing each suite with a separate key or
    signing any given suite with multiple keys?
    * (LeePen) AFAIU a particular file (suite) can only be signed with a
      single key.
      * (plasma41) See the fourth link below
* Created new 4096 GPG key for use in ceres/daedalus. Need to decide
  expiry policy (currently none) for that before the public key is
  included in devuan-keyring.
  * (plasma41) For reference:
    * [The Debian procedure](https://ftp-master.debian.org/keys.html)
      * (plasma41) If I'm reading this page correctly, it appears the
        Debian archive signing keys for each release are set to expire
        after 8 years.
    * [The announcement email for the Debian 11 signing
      keys](https://lists.debian.org/debian-devel-announce/2021/01/msg00003.html)
    * [Debian's script to generate archive keys and shard private key
      material into 5 shares of which 3 are required to recover the
      private
      key](https://salsa.debian.org/ftp-team/dak/blob/master/scripts/debian/generate-archive-key)
      * (plasma41) Also contains names and email addresses of Debian
        keyshareholders should we desire to elicit them for advice
        regarding signing key procedures.
    * https://wiki.debian.org/SecureApt#Debian_archive_key_expiry
      * (plasma41) Mentions yearly signing keys, which AFAICT is not
        still (was not ever?) done. Otherwise provides good historical
        context although it's largely outdated with regards to current
        practice. See the first link for that.
    *
      ~https://www.debian.org/doc/manuals/securing-debian-manual/deb-pack-sign.en.html
      Section 7.5.3.9.~
      * (plasma41) Largely redundant to the preceding link.
    * [A draft proposal from/for
      Ubuntu](https://wiki.ubuntu.com/AptArchiveKeySignatures)
      * (plasma41) I don't think this ever got implemented. A "One Ring
        to rule them all" type of implementation. Could be modified by
        splitting the master key into shares using Shamir's algorithm.
    * (LeePen) I am far from convinced we need to follow Debian on this
      matter.
      * (plasma41) That's perfectly fine. I'm just providing handy links
        to Debian's documentation as something to compare against as we
        evalute our options regarding key signing and expiry policy.
        * (LeePen) Of course. Thanks
  * (plasma41) FWIW, I think at minimum there should be an archive
    signing key for each release and each of those keys shouldn't expire
    earlier than the archive signing key of the corresponding Debian
    release which AFAICT is generally 8 years after key creation.


#### Email
* I can't find where <repository@???> (included in amprolla GPG
  keys) is delivered. Does anybody know? Andreas Messer has kindly
  agreed (been persuaded?) to setup our own mailserver so that we can
  have proper control of email addresses without Dyne.
  * (gl) I don't think this is to replace the lists on the dyne mail
    server. Rather it is to enable internal communications for devuan
    infrastructure, maintenance and failure reporting etc.. (Hope I got
    that right)


### amesser
* discuss setup/requirements of mail server with ralph, leepen
* wicd:
  * project page on launchpad: https://launchpad.net/wicd
  * python3 branch
    https://code.launchpad.net/~wicd-devel/wicd/+git/wicd-1/+ref/python3
  * continue development with low prio


## New Actions