1. 21 Aug, 2020 1 commit
  2. 29 Jul, 2020 1 commit
  3. 28 Jul, 2020 4 commits
  4. 03 Jul, 2020 2 commits
  5. 02 Jul, 2020 2 commits
  6. 30 Jun, 2020 3 commits
  7. 10 Jun, 2020 1 commit
  8. 08 Jun, 2020 1 commit
  9. 06 Jun, 2020 2 commits
    • intrigeri's avatar
      Automate post-release GitLab updates, using gitlab-triage (#17589) · 9e11debf
      intrigeri authored
      We will use gitlab-triage to solve other problems soon
      (https://salsa.debian.org/tails-team/gitlab-migration/-/issues/54),
      and it's the perfect tool for the job, so it makes sense
      to start using it here as well.
      
      Since gitlab-triage is not in Debian, in order to be compliant with the security
      policies applicable to Release Managers:
      
       - run gitlab-triage in Docker
       - ensure we always use the latest version of gitlab-triage,
         in a fresh Docker image based on the latest version of debian:stable
      9e11debf
    • intrigeri's avatar
      Release process: switch to a dedicated role user for GitLab automation · e566904c
      intrigeri authored
      For now that's mostly a no-op.
      
      Once we use this role user to postpone issues & MRs, this will:
      
       - avoid release managers getting subscribed to notifications
         of every postponed issue;
      
       - avoid the need for release managers' personal GitLab account
         to have access to every confidential issue in every project;
      
       - remove one blocker for migrating such GitLab automation
         to our infrastructure, so that RMs don't need the ability
         to impersonate the role-release-automation user anymore.
      e566904c
  10. 03 Jun, 2020 5 commits
  11. 02 Jun, 2020 10 commits
  12. 01 Jun, 2020 4 commits
  13. 24 May, 2020 1 commit
  14. 14 May, 2020 1 commit
    • intrigeri's avatar
      Release process: don't include revoked subkeys in the signing key downloaded... · 403f127d
      intrigeri authored
      Release process: don't include revoked subkeys in the signing key downloaded by the Upgrader (refs: #17714)
      
      All our Upgrader needs here is the set of current, valid signing subkeys: if the
      signature of the downloaded UDF is not a valid one done by one of those subkeys,
      then it'll abort. It does not matter why exactly that signature failed: it could
      be it a missing subkey, a revoked one, an expired one, or an UDF provided by an
      attacker and signed with a totally different key. As long as the signature
      verification fails, we're good.
      
      So let's not include revoked subkeys in that exported key, which every Upgrader
      downloads. In my tests, this shrinks that key from 13380 bytes down to 10349
      bytes, i.e. 22% less. That's not much; it's minor polishing rather
      a ground-breaking improvement, but still.
      
      Note that the previous instructions already filtered out expired subkeys,
      which is good. This commit does not modify this property.
      403f127d
  15. 06 May, 2020 2 commits