- Arch-dev-public - lists.archlinux.org

[arch-dev-public] Online Arch Linux Conference
by Morten Linderud 11 Aug '20

11 Aug '20

Yo! Because of COVID-19 I assume most people have had some conference plans cancelled this year. FroSCon has had an Arch Linux devroom the past years, but as we are not meeting physically I guess that isn't happening either. Thus I want to try rally some people and have an online Arch Linux conference/devroom. There are not any major ambitions really. This can be a few hours an evening, or a weekend event. We will see what we figure out :) # Ideas Some of the ideas I have had so far is as roughly: * Team Q&A * Talks/presentations * team member and the wider community * Interactive streams * See how packagers do their work? * Arch Linux installation speedruns(?) * Workshops? Feel free to email me offlist, or poke me on other platforms, if you have other great ideas that could work! # Organization To organize we would need some help and might need some roles filled. This is a shortlist of the ones I can come up with. But I'm sure there are more tasks and roles needed: * Art-work/graphics * Help figuring out streaming * Planning and handling CFP There is no requirement to be on the Arch team to contribute. If you think you have anything to contribute, please do come talk with me! Need every help one can get :) # Meeting Below is a suggested meeting date for interested parties to attend. I'm unsure if it's going to be mumble or purely text based. Date of meeting: 4th of August 19:00 CEST (UTC+2) - https://everytimezone.com/s/a5112249 IRC: #archlinux-conf @ freenode Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 3

[arch-dev-public] Use detached package signatures by default
by Anatol Pomozov 10 Aug '20

10 Aug '20

TLDR; let’s start using detached package signatures to make system updates faster. Hi folks, Some time ago there was a discussion at IRC where someone (Allan maybe?) proposed to stop using embedded PGP signatures in favor of detached signature files. I would like to bring this idea here and quantify it with some numbers. Here is a bit of technical details on this topic. Pacman has the ability to verify authenticity of package files with PGP signatures. PGP signatures add protection against undesired package modifications by a third-party and it improves security aspects of the package management. This feature can be configured per repository and the official Arch Linux repos have it enabled. Package signatures have been used by Arch Linux successfully for a couple of years now. Package signatures are stored as a part of a pacman database file (it is called “embedded signatures”). One issue with embedded signatures is that they represent a quite large chunk of database file. What is worse, a PGP signature is high-entropy data and does not compress well. I was mildly shocked to learn how much of the *.db files signatures consume. I ran experiments and repackaged extra, community databases without PGP data. For uncompressed “extra” repository size drops to 83% of its original size (though uncompressed size is not that interesting). Arch uses GZIP compressed database and in this case removing signatures reduces the “extra” database to 36.8% of its original size. To emphasize it one more time - removing PGP signatures makes this repo only 1/3 of its original size. The change is even more dramatic in case of “zstd -19” compression where the final database file is only 31% of its original size. For community.db the numbers are: uncompressed file gets 79.8% of its original size, “gzip -9” gets 33.4%, and with “zstd -19” it gets 27.51% of its original size. A database gets modified with every package update. Users need to re-download the databases where 2/3 of it are package signatures that are used only when a specific package is installed. An alternative to embedded signatures are detached signatures. These are signatures stored in a separate file next to the package itself (in a <pkg>.sig file to be specific). Instead of downloading *all* signatures every time a database is updated, detached signatures are downloaded only when a specific package is installed/updated. If Arch could switch to this model then database files become 3 times smaller that saves users bandwidth and system update time. I looked through pacman code and most components have detached signatures support already. Most of the places have a logic like this: if(pkg->embedded_sig) { use(pkg->embedded_sig) } else { sig = load_detached_sig(pkg) use(sig) } I found only 2 places where pacman does not fallback to a detached signature: 1) Keyring key check. Pacman was using embedded signatures only. This has been fixed in pacman’s commit b01bcc7d3d680 and it will be available in pacman version 6.x 2) dump_pkg_full() that dump package information. If a package uses detached signatures only then it prints “None”. I think this is fine as this function displays database entries and it does not affect the package verification process. I disabled the embedded signatures at my testing machine to use detached signatures only and things look great so far. ‘pacman --debug’ confirms that detached signatures are correctly downloaded and used to verify the package content. Given this information I would like to propose to stop using embedded signatures and move to detached signatures by default. This will require pacman 6.x or as alternative backport the fix(es) to 5.x branch. It will help to make system updates even faster, something that me and many other Arch users really love.

5 7

[arch-dev-public] Stepping down from DevOps
by Florian Pritz 01 Aug '20

01 Aug '20

Hi, As you have probably noticed, my involvement in DevOps tasks has dwindled in recent months. I have given away a few tasks to others already, but since I hardly use my root access any more, I think it is finally time to officially open up the spot and let someone else take over. Back when we started the DevOps team nearly 5 years ago (good god, time flies), Allan asked me if I wanted to lead the "infrastructure team" (old name). I am glad that I have never needed to use the team leader hat since we could discuss pretty much every problem and reach an agreement. Given that things have worked so well in the past, I'm inclined to simply discontinue the (unused) team leader hat. Considering how little, well, actually not at all, I have used the hat, most people are probably not even aware of it, so this feel like the most logical choice. I think having a core team of active people that discuss the issues and then come to an agreement has worked well in the past and it is something worth keeping. I'm still amazed by what you guys accomplished over the last year and I hope that making space and letting others join will only allow the team to be even more awesome! All that said, please disable my root access and remove me from the various infrastructure/devops/root related email aliases and services (kanboard and gitlab come to mind). Please do keep me on the mirrors(a)archlinux.org alias for now though since I still handle mirror related requests. I also see that I am the only one on the dmarc-reports@ alias. If nobody is interested in the reports, please remove the relevant line from the DMARC DNS entry in the archlinux.org zone. Also, please remove my email address from the explicit hetzner contact list. If you think of anything else that I forgot, please disable it or, if in doubt, feel free to ask on IRC if I still need it. Thanks for the journey! Florian

1 0

[arch-dev-public] AUR migration
by Giancarlo Razzolini 28 Jul '20

28 Jul '20

Hi All, In continuing with the improvements being done to our infrastructure, we're planning to migrate the AUR to another machine. This means that, during the migration, there *will* be downtime of the whole AUR. I expect the migration to take around two hours and happen either tomorrow (Friday) or on Saturday, depending on availability. Regards, Giancarlo Razzolini

7 15

[arch-dev-public] Orphaning signing-party and dependencies
by Archange 27 Jul '20

27 Jul '20

Hi there, I’ve never went far into using signing-party, and do not have time to maintain it anymore. Thus, I’m going to orphan it as well as its dependencies (nothing else requires them), and move them to the AUR unless someone steps in to maintain them within ~two weeks. The full packages list: libmd perl-data-perl perl-gnupg-interface perl-moox-handlesvia perl-moox-late perl-strictures perl-type-tiny qprint signing-party Regards, Bruno/Archange

1 0

[arch-dev-public] News draft: AUR migration
by Giancarlo Razzolini 27 Jul '20

27 Jul '20

Hi guys, Given that the SSH host keys were changed during the AUR migration, and, due to the fact that not everyone will see this on the home page for the AUR or on aur-general, I propose the following news draft: ----> AUR migration: New SSH Host keys Due to the fact the AUR was migrated to a new server, the SSH HostKeys used to pushed packages were changed in the process. These are the new keys fingerprints: Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 ECDSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI RSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 They can also be found on the AUR home page when not logged in. <---- Given this is somewhat urgent and the migration was done on Friday, I'll not wait the full 24 hours before posting this, but I'll probably post this by the end of the day, today, instead. Let me know if anyone has any objections. Regards, Giancarlo Razzolini

2 1

Re: [arch-dev-public] [aur-general] AUR migration
by Giancarlo Razzolini 27 Jul '20

27 Jul '20

Em julho 27, 2020 9:35 Henry-Joseph Audéoud escreveu: > On 24/07/2020 21:24, Giancarlo Razzolini via aur-general wrote: >> The migration is almost done. Since we are moving to a new machine, it will >> have new host keys. They are: >> >> Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 >> ECDSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 >> RSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI > > You swapped the fingerprints of keys ECDSA and RSA. From my computer, I > get that fingerprints (and Ricardo Band has the same for ECDSA): > > ED25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 > ECDSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI > > RSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 > Yes, this is correct. The configuration is with the keys swapped. I'm going to fix it and also create a news post about this. Regards, Giancarlo Razzolini

1 0

[arch-dev-public] loop device in container
by Tobias Powalowski 18 Jul '20

18 Jul '20

Hi guys, is it possible to get loop devices working in a container? I need this in archboot script. Thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-dev-public] Abandoning all my vim-* plugin packages
by Sven-Hendrik Haase 13 Jul '20

13 Jul '20

I've started using a vim plugin manager and don't use my packages anymore. They need a new home. Please show these packages some love: * vim-a * vim-colorsamplerpack * vim-doxygentoolkit * vim-guicolorscheme * vim-minibufexpl * vim-omnicppcomplete * vim-project * vim-taglist * vim-vcscommand * vim-workspace The packages are pretty low maintenance but I'd prefer if someone who actually uses them maintained them. Anything that's not taken within 2 weeks will be dropped to AUR.

1 1

[arch-dev-public] help wanted / IPP based printing/scanning
by Andreas Radke 13 Jul '20

13 Jul '20

There's some major effort going on to move from driver based scanning and printing to driverless scanning and printing both based on IPP specifications offered by newer devices. While IPP based printing is already there for some time and usable with cups+cups-filters [1] there's more work going on recently for IPP based scanning lately. There are a few projects we should probably support and add to our repos. I'm thinking about adding Sane-airscan [2][3] to extra. There's also a new ipp-usb proxy to allow IPP protocol access with USB connected printers and scanner as well [4][5]. I've prepared a simple package here of this one. Sadly my own printer is has a broken IPP implementation and thus can't be used with driverless printing [6]. My scanner is an old extra devices with plain usb connection. Both devices keep working well and I have no plan to replace them. So I cannot test anything of the new IPP stuff. If there's desire to have the new IPP stack fully available form our repos I can do the packaging because it's heavily related to recent multidevices and openprinting.org projects. But any help is welcome and I would prefer someone to become a backup and co-maintainer. If somebody has interest to help out here and maybe owns a modern IPP based multidevice please drop me a line. If nobody steps up or complains I plan to add sane-airscan and ipp-usb and maybe more if needed. -Andy [1] https://wiki.debian.org/CUPSDriverlessPrinting [2] https://github.com/alexpevzner/sane-airscan [3] https://aur.archlinux.org/packages/sane-airscan/ [4] https://github.com/OpenPrinting/ipp-usb [5] https://lists.debian.org/debian-printing/2020/07/msg00000.html [6] https://github.com/apple/cups/issues/5693

2 1