#archlinux-ports | Logs for 2017-11-10

Back
[00:03:02] <deep42thought> ok, repaired that - it should work now :-)
[00:04:53] -!- deep42thought has quit [Quit: Leaving.]
[00:09:14] -!- tyz has quit [Quit: Page closed]
[00:53:27] guys is now known as anyone
[01:11:09] jp is now known as alyptik
[01:22:06] alyptik is now known as jp
[01:35:16] -!- anathemasystemd has joined #archlinux-ports
[01:35:52] -!- anathemasystemd has quit [Quit: Leaving]
[01:44:33] anyone is now known as guys
[01:44:38] ztrawhcse is now known as anyone
[02:23:18] -!- isacdaavid has joined #archlinux-ports
[02:29:58] guys is now known as privilege
[04:21:01] -!- p71 has quit [Ping timeout: 240 seconds]
[06:25:44] -!- p71 has joined #archlinux-ports
[06:30:21] -!- deep42thought has joined #archlinux-ports
[08:24:21] -!- abaumann has joined #archlinux-ports
[08:53:01] -!- deep42thought has quit [Quit: Leaving.]
[10:10:27] -!- mrkiko has joined #archlinux-ports
[10:11:58] <mrkiko> hello guys. Thank you for your work. at this moment, I wish to thank you for your arch32 effort, even if i apreciated also other ports.
[10:12:23] <mrkiko> but without your work I wouldn't be able to use arch on perfectly working hardware. So thank you
[10:12:37] <abaumann> Thank. Users, testers and packagers always welcome.
[11:00:44] -!- abaumann has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.48/20171029041124]]
[11:42:17] -!- abaumann has joined #archlinux-ports
[11:50:09] -!- p71 has quit [Ping timeout: 248 seconds]
[11:51:07] -!- deep42thought has joined #archlinux-ports
[11:51:59] <abaumann> tried to pach linux-lts.. my local build is still running.. the initial error is gone.
[11:53:02] <deep42thought> :-)
[11:59:49] <abaumann> I think, linux needs the same treatment soon.
[11:59:56] <abaumann> the linux package, i meant.
[12:00:20] <deep42thought> :-D
[12:00:59] <deep42thought> if it's something needed on linux in general, then we should add it to the PKGBUILD mangling (like the adding of 'i686' to the arch array)
[12:01:03] <deep42thought> ;-)
[12:01:36] <abaumann> it's very specific. using a config-i686 instead of config for the kernel config and copying a Makefile_32 at installation time.
[12:01:47] <abaumann> more to follow.. :-)
[12:02:38] <rewbycraft> "PKGBUILD mangling"
[12:02:56] <abaumann> "lot's of irritating sed commands in sequence"
[12:02:57] <rewbycraft> Now I can just imagine someone writing a tool that can apply sets of mangle rules onto PKGBUILDS like iptables can do for packets
[12:03:21] <rewbycraft> sed commands can be irritating yes, but that's regex
[12:03:38] <rewbycraft> When you have 99 problems and use regex to solve one, you have 200 problems
[12:03:48] <abaumann> I thought more about a diffing tool for the gitsvn repos to find more diffs between trunk/x86_64 and i686 PKGBUILDs
[12:04:05] <rewbycraft> Diffing would work, but if they updated the pkgbuild, you'd have to manually update our copy
[12:04:36] <rewbycraft> Where a set of transform rules would enable the software to handle the most common pkgbuild changes automatically
[12:04:53] <abaumann> No worries. Updating is not so much the problem, finding out it changed would already help.
[12:04:59] <rewbycraft> Hm. True
[12:05:06] <abaumann> Otherwise I have a tool for this: called diff and patch. ;-)
[12:05:14] <rewbycraft> I may try to port a script I have for another project
[12:05:27] <abaumann> ah.. ok. sounds interesting
[12:05:29] <rewbycraft> Basically pulls the repo and tells you in an overview which files have been changed since the last run
[12:06:07] <abaumann> sounds handy.
[12:06:09] <rewbycraft> So a minor modification would be to point it at the arch PKGBUILD repo and have it write the output to a file
[12:06:22] <rewbycraft> And then merge the file with the pre-existing "things changed" file (remove duplicate entries)
[12:06:36] <rewbycraft> And the file ends up as a sort-of todo list
[12:07:35] <rewbycraft> It'd behave kinda like "did file change and isn't on the list, add it"
[12:07:43] <rewbycraft> So you could check if the changes are worth looking at
[12:07:57] <rewbycraft> And then just remove the line from the file if you've done that
[12:08:29] <rewbycraft> I could probably do some minor sed stuff to make the output in the form of "<repo> <package>"
[12:09:27] <abaumann> I would have hoped that upstream keeps the repo-i686 directory as is for a while, so we could produce an initial diff to trunk
[12:10:15] <jelle> don't see a reason for us to keep it
[12:11:05] <abaumann> I made a snapshot of the current state, so no problem actually.
[12:11:49] <abaumann> lunchtime, sorry about that.. have to hyrry..
[12:37:36] <deep42thought> upstream does not need to keep the repos/*-i686 dirs nor i686 specific files - it's all in git, just check out the last version with i686 and take a diff there
[12:38:16] <deep42thought> additionally I don't understand what you're going to monitor: changes in PKGBUILDs? That's like ~1 to 5 per hour, sometimes a lot more
[12:38:46] <deep42thought> but of course, we can talk about / consider different kind of "patching" (e.g. patching instead of appending)
[12:41:44] -!- p71 has joined #archlinux-ports
[13:06:41] <deep42thought> there are currently two options for changing non-PKGBUILD source files:
[13:06:58] <deep42thought> 1st: override the file by giving one with the same name in our modification repository
[13:07:48] <deep42thought> 2nd: apply a patch by providing a patch file, adding corresponding source and checksum entries in the PKGBUILD and applying it in the PKGBUILD's prepare() function
[13:09:29] <deep42thought> I can currently only think of simplifying the 2nd option
[13:19:22] -!- Vollzornbrot has joined #archlinux-ports
[13:19:25] <Vollzornbrot> Hello Guys
[13:20:13] <Vollzornbrot> anyone from archlinux32 here?
[13:20:22] <deep42thought> yes
[13:20:24] <deep42thought> Hi!
[13:20:46] <Vollzornbrot> hey :) good, i can make a mirror for the packages of archlinux32
[13:20:55] <deep42thought> in germany?
[13:21:01] <Vollzornbrot> yes
[13:21:11] <Vollzornbrot> 1Gbit network
[13:21:13] <deep42thought> thanks!
[13:21:25] <deep42thought> may I ask, where?
[13:21:41] <Vollzornbrot> i think is on Gunzenhausen, Hetzner ;)
[13:21:48] <Vollzornbrot> i write german too :P
[13:22:21] <deep42thought> english is fine on this channel - others want to read it, too ;-)
[13:22:46] <Vollzornbrot> 3 domains you can choose: rmatthes.de / vollzornbrot.de / heradon.eu
[13:22:50] <Vollzornbrot> you can decide ;)
[13:22:57] <Vollzornbrot> subdomain pls :D
[13:23:03] <deep42thought> I like vollzornbrot
[13:23:11] <Vollzornbrot> good me too ^.^
[13:23:57] <Vollzornbrot> can you tell me to sync the repo? (i can give a vserver to build packages too) my server is very lazy at the moment
[15:29:38] <deep42thought> ok, I have to leave now
[15:29:51] <deep42thought> thanks again, Vollzornbrot, for mirroring and providing a build slave :-)
[15:30:48] -!- deep42thought has quit [Quit: Leaving.]
[15:32:52] <privilege> deep42thought: adding the makefile line shouldn't be too hard, really. read -r -d '' package_new << '__EOF__' ... __EOF__ and perform the necessary sorcery to insert it on the line-before-last
[16:20:11] <abaumann> deep42thought: I'll make a simple diff between trunk and repo-i686 and backport 32-specific stuf back into the PKGBUILDs
[16:21:00] <abaumann> I didn't want to suggest a new way of doing the diffs, I'm fine with the current sed. I was just pointing out that the proposed diff tool is maybe overkill, diff/patch does the trick.
[16:26:13] -!- Vollzornbrot has quit [Remote host closed the connection]
[16:30:54] <privilege> It's probably my fault :) I initially suggested it would be easy to add new elements to an array and suchlike by appending arr+=(foo)
[16:31:04] -!- jemadux_ has joined #archlinux-ports
[16:31:37] <privilege> I did not, however, suggest overriding functions by sed'ing the existing function definition, which granted is pretty clever
[16:32:27] <abaumann> It's functional prorgamming in bash, verey clever indeed. :-)
[16:33:08] -!- jemadux has quit [Ping timeout: 240 seconds]
[16:33:30] <abaumann> Vollzornbrot: thanks for the additional mirror :-)
[16:34:25] <abaumann> Only if for instance applying an existing Debian patch is easier and if the diff is bigger, diff/patch is the preferred way.
[16:39:29] -!- krumelmonster has joined #archlinux-ports
[16:39:39] -!- krumelmonster has parted #archlinux-ports
[16:40:19] -!- facundo has joined #archlinux-ports
[16:40:53] <privilege> Well, the only thing going on in the arch32 PKGBUILDs is metaprogramming on the PKGBUILDs themselves. And prepare() can always use either sed or patch to modify the source code so that's nothing new. I doubt debian patches will work to modify our build() and package() functions though :p (assuming that's what you were suggesting?)
[16:41:16] <privilege> Anyway, AFAICT the current system works fine.
[16:41:54] <privilege> (And I really like the fact it is relatively easy to tell what is being changed, compared to archlinuxarm)
[16:41:55] <abaumann> No, Debian patches would patch for instance the sources. And I'm hesitating anyway from a legal/niceness point of view, if this is the right thing to do to use patches of other Linux distributions.
[16:42:06] <privilege> (Which just includes modified PKGBUILDs)
[16:42:55] <privilege> abaumann: distro patches are licensed the same license as the source, and sometimes are actually upstream patches :p
[16:43:02] <abaumann> patch files are more britle. Clever formulated sed rules can cope with changes in the upstream PKGBUILD much better, for instance s/x86_64/i686/g is supperiour to providing a patch file
[16:44:25] <abaumann> the archlinux way is to do minimal patching, so the current system is fine.. :-)
[16:44:42] -!- facundo has quit [Quit: Konversation terminated!]
[17:05:35] -!- privilege has quit [Ping timeout: 268 seconds]
[17:07:54] -!- dopsi has quit [Quit: ZNC - http://znc.in]
[17:08:34] -!- dopsi has joined #archlinux-ports
[17:18:03] -!- privilege has joined #archlinux-ports
[17:37:22] -!- yar has quit [Ping timeout: 260 seconds]
[17:40:46] -!- yar has joined #archlinux-ports
[17:54:35] -!- deep42thought has joined #archlinux-ports
[18:05:05] -!- privilege has quit [Ping timeout: 240 seconds]
[18:15:47] -!- krumelmonster has joined #archlinux-ports
[18:18:22] -!- privilege has joined #archlinux-ports
[18:22:39] -!- tyzoid has quit [Ping timeout: 268 seconds]
[18:23:37] -!- tyzoid has joined #archlinux-ports
[18:27:03] -!- krumelmonster has quit [Ping timeout: 258 seconds]
[18:37:40] -!- krumelmonster has joined #archlinux-ports
[18:43:13] <abaumann> huh? is it just me, but I only see namcap logs on the build server, where are the other logfiles?
[18:44:16] -!- krumelmonster has quit [Remote host closed the connection]
[18:47:11] <deep42thought> the build logs were deleted yesterday
[18:47:20] <deep42thought> when everything was put onto the deletion list
[18:47:32] <deep42thought> due to a bug in libmongoc
[18:48:09] <deep42thought> it checkdepended on mongodb, which is blacklisted, and pulled everything else into the black (listing) hole ...
[18:48:26] <abaumann> ui. :-)
[18:48:47] <abaumann> ...a well..
[18:49:12] <abaumann> 2017-11-10 07:59 python-sympy, hanging?
[18:49:17] <deep42thought> I really should put some emergency break into the get-package-updates script
[18:49:31] <deep42thought> lemme check
[18:49:35] <abaumann> just good to know, why it happened.
[18:49:58] <deep42thought> it's running tests ...
[18:50:06] <deep42thought> "sympy/integrals/tests/test_meijerint.py[25] ......www", currently
[18:50:14] <abaumann> wow! that's some testing!
[18:50:24] <deep42thought> and it's already the fourth trial
[18:51:27] <deep42thought> that's exactly the reason why we need more than just one build slave :-)
[18:52:32] <abaumann> agreed. :-)
[18:53:23] <deep42thought> I didn't have the chance/time yet to set vollzornbrot's build slave up
[18:53:42] <abaumann> linux-lts builds and boots now, but Makefile_32.cpu is missing. Just the build on my old machine is really slow.. :-(
[18:53:55] <abaumann> that's why I wanted to peek at the build logs of it..
[18:54:49] <abaumann> vollzornbrot, really cool name, if his first name is Bernd.. ;-)
[19:06:19] <deep42thought> What I also wanted to discuss publicly: What do you (all) think of the idea to hand out more master keys, e.g. to tyzoid, rewbycraft, abaumann (or some non-empty subset of them)?
[19:07:19] <deep42thought> It seems, currently, that the bottleneck for setting up a build slave is the (gpg made) requirement of three signatures from our three master keys
[19:11:05] -!- isacdaavid has quit [Quit: Leaving.]
[19:12:27] <privilege> who currently has them?
[19:12:35] <deep42thought> I, Polichronucci, City-busz
[19:13:00] <privilege> having only three seems sub-optimal, there is a reason archlinux has 5 master keys
[19:13:17] <deep42thought> that's, what I was thinking
[19:13:27] <deep42thought> alarm has only 3, but also has only one packager key
[19:13:29] <privilege> I say go for it.
[19:15:53] * WarheadsSE wave
[19:16:07] <WarheadsSE> That's because PlugBuild does all the work.
[19:17:15] <WarheadsSE> ArchStrike does it slightly differently, where the packages are signed by the key of the owner of the farm node that built said package.
[19:17:17] <deep42thought> WarheadsSE: I thought so
[19:18:10] <deep42thought> I'm not really criticising your architecture, just saying, I copied the "three" from your scripts and the rest more from archlinux
[19:19:42] <WarheadsSE> It all comes down to how you might architect an automated build system.
[19:22:35] <deep42thought> yes, my thought regarding this was: I need to trust the build slaves anyway, so they should/can also hold the signing keys
[19:25:04] <WarheadsSE> ALARM has a complete farm in one location, but that is due to the hardware requirements. AS uses distributed builder nodes connected securely to a VPS hosting the master ( I leave it to them to disclose networking topology beyond that)
[19:25:46] <WarheadsSE> But then _Cthulu201 is here as well
[20:15:41] -!- isacdaavid has joined #archlinux-ports
[20:19:53] -!- abaumann has quit [Remote host closed the connection]
[20:20:07] -!- because has quit [Ping timeout: 260 seconds]
[20:22:12] -!- because has joined #archlinux-ports
[21:12:20] -!- isacdaavid has quit [Quit: Leaving.]
[21:21:40] -!- {levi} has joined #archlinux-ports
[21:27:23] <{levi}> Thanks for fixing the signing bug on the i686 packages already. Tried switching to the i686 repo yesterday, couldn't get it to work, just tried again and it seems to be working thus far.
[21:27:55] <deep42thought> good to hear :-)
[21:31:03] <{levi}> Done, and it seems to have at least generated my initcpios, but I won't see till tomorrow whether it'll actually boot.
[21:33:04] <{levi}> Should be okay though - I was running a reimaged i686 build on my old build server for a couple months, but I've retired that machine now.
[21:33:23] <{levi}> Huh?
[21:36:05] <{levi}> Okay that was graphical weirdness. Looks like it decided not to render the entire first line of my 20:33:04 post
[21:39:27] <{levi}> Maybe I should reboot in that case. TTFN
[21:39:37] -!- {levi} has quit [Quit: Leaving]
[21:42:09] -!- {levi} has joined #archlinux-ports
[21:42:12] <{levi}> I'm back!
[21:42:24] <deep42thought> :-)
[21:45:48] <fsckd> oops Arch Linux https://i.imgur.com :P
[21:46:38] <deep42thought> we're not forgotten :-)
[21:53:18] <rewbycraft> deep42thought: I'm all for adding more master key holders.
[21:53:34] <rewbycraft> But keep it limited to people known to be trustworthy
[21:54:05] <deep42thought> how do I evaluate that?
[21:54:23] <deep42thought> s/I/we/
[21:54:38] <rewbycraft> That I do not know
[21:54:56] <rewbycraft> Maybe people who've been here for a while and have shown to be around at least regularly
[21:57:52] <tyzoid> deep42thought: DO I count as a master keyholder?
[21:58:05] <tyzoid> afaik, I don't
[21:58:10] <deep42thought> you don't
[21:59:00] <rewbycraft> I wouldn't mind helping out. But it'd have to wait a few days as I'm at my parents' and my keys are on a secure flash drive at my appartment
[21:59:35] <deep42thought> that sounds like a paranoid enough person to hold a master key :-)
[22:00:27] <rewbycraft> It's an encrypted flash drive that I keep in an airtight tupperware box
[22:00:46] <rewbycraft> It's not in a safe because, well, you'd crack the safe well before you'd crack the drive
[22:00:56] <rewbycraft> (And I don't have space for a safe)
[22:01:29] <tyzoid> rewbycraft: Is that just a regular flash drive that's encrypted?
[22:01:40] <tyzoid> Or is it a special cryptographic key drive?
[22:02:32] <rewbycraft> Flash drive. The special crypto drives are too expensive forme
[22:02:36] <rewbycraft> Given the limited use
[22:02:40] <rewbycraft> I mostly use gpg to encrypt my backups
[22:03:00] <rewbycraft> But it should be more or less decently setup
[22:03:08] <{levi}> I figured out how to use dmcrypt to mount my backup drive as encrypted
[22:03:15] <rewbycraft> There's a master key on the drive, with the public available online
[22:03:22] <rewbycraft> And I've got some subkeys on my laptop
[22:04:49] <tyzoid> What do you guys think about https://www.yubico.com
[22:04:51] <phrik> Title: YubiHSM - Hardware Security Module HSM for your Server | YubicoYubiHSM - Hardware Security Module HSM for your Server | Yubico (at www.yubico.com)
[22:05:23] <rewbycraft> Cool but expensive
[22:05:31] <tyzoid> Not as expensive as a full HSM
[22:07:36] <{levi}> I just bought a standard USB drive in a metal enclosure with a hole so I can put it in my key wallet.
[22:07:38] <tyzoid> but yeah, I agree.
[22:08:28] <tyzoid> Nice. I might do something like that.
[22:08:48] <tyzoid> I might go for a microsd card on my keyring too
[22:09:03] <tyzoid> something less prone to break than a full usb drive on a keychain
[22:09:58] <{levi}> Yeah, maybe. Mine is just a stainless steel sheet shaped over a PCB though, so it seems quite robust
[22:10:41] <rewbycraft> As I said, I keep the actual keys on the flash drive, but I have some keys under the master key that are on my laptop
[22:10:45] <rewbycraft> Kindof like a "working set" of keys
[22:10:53] <rewbycraft> If they get stolen, I can revoke them using the master key
[22:11:37] <deep42thought> rewbycraft: that sounds like a really solid setup
[22:11:46] <{levi}> Yes, I guess I could do that too with LUKS. I'll leave a secure password on it so I can still access the volume without the key if I lose it.
[22:11:52] <rewbycraft> That's the idea.
[22:12:07] <tyzoid> Mine are password protected, but the security isn't great.
[22:12:08] <rewbycraft> But if I were to have a master key, it'd be a new subkey of the main key
[22:12:11] <tyzoid> I need some good offline storage
[22:12:14] <rewbycraft> So I'd need the flash drive for that
[22:12:51] <tyzoid> deep42thought: Who's in charge of the master key?
[22:12:58] <deep42thought> I, Polichronucci, City-busz
[22:13:23] <deep42thought> I got a gnupg smart card for it, Polichronucci planned the same, and as for City-busz I have no idea
[22:13:41] <deep42thought> but he's the TU, so I trust him ;-)
[22:13:54] <tyzoid> deep42thought: How do you give someone else master key status?
[22:14:14] <tyzoid> Is there a key above yours that grants that?
[22:14:31] <deep42thought> no, that's the problem
[22:14:39] <deep42thought> you need to create the package and that's it
[22:15:10] <tyzoid> so basically, if you package my key in archlinux32-keyring, I automatically get master status?
[22:15:13] <deep42thought> there is no such thing as a general trust anchor _above_ the master keys
[22:15:17] <deep42thought> yes
[22:15:23] <privilege> tyzoid: generally you'd bundle it in the keyring package and have the post_install sign it with the local signing key generated by pacman-key
[22:15:40] <tyzoid> so... theoretically I could package my own key, upload it, and get elevated status
[22:15:44] <privilege> deep42thought: (excepting the aforementioned local signing key)
[22:15:59] <deep42thought> privilege: which is not general
[22:16:17] <tyzoid> If only we had enough local people
[22:16:35] <deep42thought> tyzoid: hmm?
[22:16:36] <rewbycraft> "local"?
[22:16:51] <deep42thought> should I ask my neighbours?
[22:16:57] <tyzoid> Yeah. Not really easy to have a meetup of arch32 developers
[22:17:16] <deep42thought> it's quarter past 10 here, probably shouldn't ring doors at this time
[22:17:17] <privilege> tyzoid: see /usr/share/pacman/keyrings/archlinux-trusted which is the list of master keys, alongside archlinux.gpg which has all Dev/TU keys
[22:17:22] <tyzoid> Not asking neighbors, but if we had a meetup, we could distribute smartcards to core people
[22:17:51] <tyzoid> then the smartcards would unlock the true master key
[22:20:34] <deep42thought> sry, I don't get it
[22:22:49] <tyzoid> Here's how I see it:
[22:22:53] <deep42thought> the current setup is good, despite the point, that anyone with a package key can replace the archlinux32-keyring package
[22:23:05] <tyzoid> Problem: No authority to add/revoke keys
[22:23:15] <tyzoid> Solution: create master key above "master keys"
[22:23:22] <tyzoid> Problem: How to control new master
[22:23:29] <tyzoid> Solution: Smart cards/keysharding
[22:23:39] <tyzoid> Basically, you give 4-5 devs smartcards
[22:23:56] <tyzoid> and whenever we need to use the master, we reconviene, and present our cards to use the key
[22:24:09] <tyzoid> only need 3 out of 5 cardholders present
[22:24:14] <tyzoid> or whatever you want to set the number at
[22:24:39] <tyzoid> That's why I said it's a shame that we're not more local.
[22:24:57] <tyzoid> since it's relatively difficult for just me to cross the atlantic.
[22:25:00] <deep42thought> I understand the advantage of "being local"
[22:25:04] <rewbycraft> With that system, I'd probably not be available becuase of the large amount of travelling involved. Leaving the country is somewhat impractical for me as I need to use public transit (aka trains trains trains)
[22:25:16] <tyzoid> ^ Exactly my point too.
[22:25:23] <{levi}> And I'm even on an island
[22:25:32] <rewbycraft> (and I get free trains inside the country, but not outside)
[22:25:32] <{levi}> Not that I'm a candidate for a master key mind you
[22:25:41] <tyzoid> Even if we set the point as Paris, that means I'd need to fly through London on the way
[22:26:07] <rewbycraft> I'd have to take trains, 60 or so euro one way
[22:26:07] <tyzoid> and deep42thought and andreas would need to travel quite a ways
[22:26:15] <rewbycraft> (I acually looked it up once)
[22:27:29] -!- privilege has quit [Ping timeout: 248 seconds]
[22:27:29] <tyzoid> rewbycraft, compared to that, think >1k USD for flights one way
[22:27:38] <deep42thought> I think, meeting in person is a no-go
[22:27:40] <tyzoid> yeah
[22:27:41] <rewbycraft> ^
[22:27:52] <tyzoid> it'd be cool, and hella-secure
[22:27:59] <tyzoid> but mostly impractical
[22:28:01] <{levi}> Not that it really should for a distributed project like this
[22:29:43] <rewbycraft> The thing about security, when it is most critical, the level you attempt to achieve is inversely proportional to practicality
[22:29:59] <rewbycraft> The secret is to find a good middle-road
[22:30:34] <deep42thought> I think, we can skip the technical verification of (ex)changing the masterkeys - anyone with a packager key can replace the package and add basically arbitrary master keys
[22:30:51] <deep42thought> if it's done far enough up in the chain, every client will install the keys
[22:31:20] <deep42thought> what we _should_ do, however, is define some conditions that need to be met to make some changes to the master key(s)
[22:31:41] <{levi}> As long as someone doesn't replace the package with just their own key, I'd hope their misdemeanour would be discovered early and reverted.
[22:33:36] <tyzoid> That's certainly the hope
[22:33:56] <tyzoid> deep42thought: Do we have any checks against this?
[22:34:01] <deep42thought> nope
[22:34:08] <tyzoid> how hard would it be to do?
[22:34:34] <deep42thought> we can block updates on archlinux32-keyring except if signed by some keys
[22:34:43] <{levi}> If you receive an update to the archlinux-keyring, check that it's been preannounced somewhere, I guess
[22:35:06] <{levi}> I'd expect any additions to the archlinux32-keyring to be discussed in this channel before they go live, for example
[22:35:08] <deep42thought> but the point is, that this works with any package in base
[22:35:32] <deep42thought> e.g. you make an pseudo-update of pacman which installs new archlinux-keys and removes all current
[22:36:17] <deep42thought> and we won't announce each and every update ...
[22:36:28] <deep42thought> to all base packages, I meant
[22:36:47] <{levi}> No, only updates the the keyring are especially dangerous, I'd have thought
[22:37:41] <deep42thought> the post_upgrade magic can do everything, I think
[22:39:02] <{levi}> Yeah, it's all scriptable, isn't it?
[22:39:28] <deep42thought> you want me to detect if an post_upgrade does unrighteous things to the keyring?
[22:39:53] <{levi}> Oh, I see what you mean
[22:40:21] <{levi}> There's a pacman check you can do to check packages haven't been corrupted I think.
[22:40:46] <{levi}> They'd have to go a long way to replace all of the fingerprints and so on.
[22:41:21] <deep42thought> Hmm?
[22:41:26] <deep42thought> What fingerprints
[22:41:35] -!- privilege has joined #archlinux-ports
[22:41:46] <{levi}> I assume pacman fingerprints files so it can check them
[22:42:18] <deep42thought> the signing of master keys is not fingerprinted
[22:42:25] <rewbycraft> In my opinion, there is not a good way of protecting against bad actors screwing with the keyring package or hijacking a package.
[22:42:34] <deep42thought> right
[22:42:40] <deep42thought> that's what I wanted to say
[22:42:54] <{levi}> Just try not to let bad actors be submitters
[22:43:59] <rewbycraft> Pretty sure that's what we're tryign anyway.
[22:44:12] <rewbycraft> That said, until reproducable builds become a thing, we can't guarantee security
[22:44:45] <{levi}> Indeed
[22:45:01] <rewbycraft> So some level of trust is needed
[22:46:09] <deep42thought> so what check should I add?
[22:47:25] <deep42thought> simply that the masterkeys in the archlinux32-keyring package are signed by three out of a number of trusted master-master-keys?
[22:47:29] <tyzoid> deep42thought: I guess just on the master mirror, do a periodic gpg verification of the archlinux32-keyring package
[22:47:38] <tyzoid> and make sure it's only signed by the few allowed
[22:47:51] <deep42thought> that reminds me of something
[22:47:58] <tyzoid> The difficult thing is if a mirror operator decided to do something nerfarious too
[22:48:02] <tyzoid> but that'd be less widespread.
[22:48:06] <deep42thought> I wanted to add a check, that package signatures are not only present, but also valid :-)
[22:48:12] <tyzoid> ^
[22:48:24] <deep42thought> (in the buildmaster)
[22:48:42] <tyzoid> deep42thought: You should also set your "Valid" critera to that of "a standard arch32 installation would accept the package"
[22:48:52] <deep42thought> right
[22:48:56] <deep42thought> that's what I meant
[22:49:06] <rewbycraft> I can up the disk space on the build master if needed for such a setup
[22:49:21] <tyzoid> Not sure it would require more disk space
[22:49:28] <deep42thought> ^
[22:50:27] <rewbycraft> I'd imagine a way to test would be to maintain a "clean" chroot env
[22:50:38] <deep42thought> ah, ok
[22:50:40] <rewbycraft> And see if if complains
[22:51:04] <rewbycraft> It'd just contain the "base" group
[22:51:17] <rewbycraft> But I'm sure you get my idea
[22:51:25] <deep42thought> yes
[22:51:41] <deep42thought> this should be part of the testing infra
[22:51:53] <deep42thought> once we got to set that up ...
[22:52:31] <rewbycraft> That reminds me, I'm pretty sure I forgot to restore *something* after the outage...
[22:54:10] <{levi}> Pfft, if nobody's complained yet ;)
[22:54:32] <rewbycraft> The server's down 10+G in ram usage
[22:54:37] <rewbycraft> So something's off that shouldn't be
[22:54:43] <deep42thought> if nobody complained yet, maybe your setup is suprafluid? ;-)
[22:54:54] <deep42thought> (That's what I think, usually)
[22:55:00] <rewbycraft> Oh... OOOHHH
[22:55:03] <rewbycraft> I see what died
[22:55:12] <rewbycraft> What died was my git server.
[22:55:30] <rewbycraft> I haven't had the time to use git this week, so didn't notice
[22:55:53] <tyzoid> lol
[22:55:58] <rewbycraft> Yeeppp...
[22:56:03] <rewbycraft> It's dead jim
[22:56:07] <tyzoid> Scream test successful.
[22:56:09] <rewbycraft> Oh boy, data base recovery
[22:56:15] <rewbycraft> That's not gonna be fun
[22:56:21] <rewbycraft> (Totally dead: https://git.roelf.org)
[22:56:45] <{levi}> Heh, nice 404
[22:57:02] <rewbycraft> 500, not 404
[22:57:11] <rewbycraft> It intercepts the 500 errors from the backend and serves that
[22:57:13] <{levi}> :)
[22:57:25] <rewbycraft> That's just my frontend loadbalancer/reverse proxy doing that
[22:59:07] <tyzoid> 500? not 501?
[22:59:18] <tyzoid> s/501/502/
[22:59:34] <rewbycraft> The 50x series
[22:59:56] <tyzoid> ah
[23:06:37] -!- jemadux_ has quit [Read error: Connection reset by peer]
[23:08:47] <rewbycraft> Excellent. Booting back up
[23:13:59] <tyzoid> :)
[23:16:32] <{levi}> Yep, seems back