[libreoffice-website] Minutes from the Tue May 16 infra call

Participants
============
1. guilhem
2. cloph

Agenda
======

 * infratools (GitLab) deprecation
   + june 30 at the latest
   + cleaned-up repo with `git filter-branch` (need to clone again)
   + new repo https://git.libreoffice.org/infra/salt, subject to manual
     inspection by infra team members, MC BoD before removing the lock
   + cloph: didn't have time to look at it yet, will do early next week
   + pending: move infra-related repos (bugzilla, gitiles, whatcanidoforlibreoffice
     etc) to /infra/*, will require changing the remote url (won't add
     symlink/redirects, we're so few right now it's doesn't seem worth it)
 * pending OS upgrades (Debian 10.4 released on May 9)
   + still 3 hypervisors to upgrade
 * salt vulnerabilities: CVE-2020-11651 and CVE-2020-11652 (postmortem)
   + as bad as it gets, gives attackers root access on the minions
     - https://labs.f-secure.com/advisories/saltstack-authorization-bypass
     - https://blog.f-secure.com/new-vulnerabilities-make-exposed-salt-hosts-easy-targets/
     - https://github.com/saltstack/salt/issues/57057
   + Not affected AFAICT, *pure luck* (audit system was working and not affected
     by this)
   + measures for defense in depth (not exhaustive, suggestions welcome)
     - firewall the salt master (open master ports to intranet, our subnet only)
     - don't run the salt master as root
     - shutdown the salt master when not in use
       . guilhem: not sure how to do that
       . cloph: systemd timer to kill salt-master if there was no log activity
         in 15min or so (check if there are any pending jobs)
     - increase the job cache/log retention period
     - don't allow the master to manage itself in default operations, just like
       for other boxes needed in disaster recovery such as mail and backup
     - rekey the master and all minions (don't think it's needed but doesn't
       hurt)
 * cloph: georep: xfs uses a too small inode size for gluster attributes so
   gluster duplicates these (w/ rsnapshot's hardlinks), using a larger inode
   size gives a perf boost of ×4 or more
   - backups of large file systems (download archives, extensions) are much
     faster, though it can also be thanks to the fact that georep is off right
     now (and no parallel scrubbing)
 * [rdm#3097] Try out MirrorBits as replacement for MirrorBrain
   - scanning is FTP/RSYNC only, no HTTP: https://github.com/etix/mirrorbits/issues/77
     . 24 enabled mirrors without FTP/RSYNC URLs
   - 19 of these use HTTP/1.1, so no multiplexing, scanning would at best cost
     one roundtrip per file
   - (none use HTTP/1.0 so we can use the same TCP stream resp. TLS session)
   - a full HTTP-based scan (excluding .asc) would cost ~1.8k GET/HEAD requests
     . could even do a partial randomized scans if that's too slow
   - whether we scan each file or just the index.html and parse it we'd need to
     implement our own scanner
   - AI guilhem: document listing-only rsyncd setup on the wiki and point mirror
     operators to it (will be good for mirrorbrain to, HTTP scanning is slow,
     tedious and error prone)
   - AI guilhem: adapt mirrorbrain-scanner to make it work with mirrorbits
     (parsing HTML index pages)
 * Upcoming HTTP mirror deprecation: 
https://security.googleblog.com/2020/02/protecting-users-from-insecure_6.html
   - chromium 81 (march) console warning, 84 (aug) warn popup, 85 (sept) block
     . 24h metrics: 2k 80, 63k 81, 150 83, <100 ≥84, no complains so far (not
       clear what would the concrete impact be with redirects)
   - https://listarchives.libreoffice.org/global/website/msg15648.html
     . currently 26 http:// mirrors vs 70 https:// , in a good position to
       disable insecure mirrors without notice if needs be
   - AI guilhem: write wiki page and invite mirror operators to deploy HTTPS on
     their site (along with the rsync daemon :-))
 * Next call: Tue Jun 16 16:30 UTC 2020

-- 
Guilhem.

-- 
To unsubscribe e-mail to: website+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy