#archlinux-ports | Logs for 2017-07-17
Back
[01:17:04] bi is now known as dwm
[02:22:12] -!- eschwartz has quit [Remote host closed the connection]
[02:24:18] -!- eschwartz has joined #archlinux-ports
[02:43:07] -!- isacdaavid has joined #archlinux-ports
[04:19:01] -!- {levi} has quit [Quit: Leaving]
[05:48:27] -!- eschwartz has quit [Remote host closed the connection]
[05:48:52] -!- eschwartz has joined #archlinux-ports
[06:22:35] -!- deep42thought has joined #archlinux-ports
[06:36:01] -!- deep42thought has quit [Remote host closed the connection]
[08:24:23] -!- deep42thought has joined #archlinux-ports
[08:27:05] -!- isacdaavid has quit [Quit: isacdaavid]
[09:46:09] -!- Faalagorn has quit [Ping timeout: 248 seconds]
[10:00:01] -!- Faalagorn has joined #archlinux-ports
[11:50:36] -!- p71_ has joined #archlinux-ports
[11:51:58] -!- p71 has quit [Ping timeout: 268 seconds]
[11:52:31] p71_ is now known as p71
[14:45:09] -!- tyzoid has joined #archlinux-ports
[14:45:48] <tyzoid> deep42thought: I'm back from vacation
[14:46:30] <deep42thought> tyzoid: o/
[14:46:37] <deep42thought> I hope, you're relaxed :-)
[14:46:42] <tyzoid> Not really
[14:46:53] <tyzoid> It was a tour of the national parks, so we did a lot of hiking
[14:47:12] <tyzoid> But it was fun :)
[14:47:17] <deep42thought> :-)
[14:47:45] <tyzoid> so I was trying to keep up with the irc logs, it looks like we've found a solution to the circular dependencies?
[14:49:34] <deep42thought> to the one with perl-gtk and perl-pango
[14:49:44] <deep42thought> (not sure, these were the exact names)
[14:49:53] <tyzoid> I believe so
[14:51:25] <tyzoid> deep42thought: I assume you've seen the forum post about the archiso testing?
[14:51:48] <deep42thought> I believe so, lemme check
[14:51:50] <tyzoid> I'm not sure that pacman has archlinux32-keyring as a dependency for i686, can you double check that?
[14:51:58] <deep42thought> it should
[14:52:42] <deep42thought> the one in testing has
[14:52:46] <deep42thought> the one in core does not
[14:53:37] <tyzoid> ah
[14:53:43] <tyzoid> Do you know when we're making that move?
[14:54:09] <deep42thought> dunno
[14:54:15] <tyzoid> The iso doesn't have that, since I built the iso in the prod branches
[14:54:31] <deep42thought> there are a lot of builds broken, which let me assume that something else is faulty :-/
[14:54:38] <tyzoid> probably
[14:55:01] <deep42thought> but I think, we might be safe, moving pacman to stable
[14:58:22] <tyzoid> deep42thought: I've been out of the loop, but I'd prefer safety at this point.
[14:58:36] <tyzoid> Let's see if we can't reduce the build errors and have some testing done in the testing repo
[14:59:15] <deep42thought> there should be a lot of build errors due to harder enforcements on the build tools, but actually I tried to rebuild all depencies
[15:02:00] <tyzoid> deep42thought: The other thing we may want to consider is potentially moving to #archlinux32
[15:02:36] <deep42thought> I'm unfimiliar with the registration of a channel on freenode, but it may be worth it
[15:03:43] <tyzoid> deep42thought: I have it registered under my name, so we've got it locked if we need it
[15:04:36] <deep42thought> "#archlinux32 requires an invitation"
[15:05:21] <tyzoid> deep42thought: Yeah, I'm getting that fixed
[15:07:51] <tyzoid> deep42thought: Alright, you should be able to join onw
[15:07:53] <tyzoid> now*
[15:08:25] <deep42thought> "Cannot send to channel" - do I need voice?
[15:09:04] <tyzoid> hmm
[15:10:26] <tyzoid> I'm going through the list of modes to see what the issue is
[15:10:47] <deep42thought> +v
[15:11:03] <tyzoid> deep42thought: You should be good now
[15:11:08] <tyzoid> I removed the +m flag
[15:11:12] <brtln> honestly I'm fine with you staying here and giving someone admin rights
[15:12:10] <deep42thought> Who else is expected to come to #archlinux-ports besides to-i686-porters?
[15:12:51] <brtln> any crazy people that want to run arch on some ppc64le
[15:12:59] <brtln> which probably won't happen
[15:13:21] <deep42thought> you think archers aren't crazy? ;-)
[15:14:21] <brtln> they totally are, but before that happens, the less channels, the better
[15:14:39] <deep42thought> good point
[15:19:38] <tyzoid> brtln: We'll keep the channel locked until we determine we need it later
[16:35:06] -!- deep42thought has quit [Quit: Leaving.]
[17:24:38] -!- grazzolini has joined #archlinux-ports
[17:24:43] -!- grazzolini has parted #archlinux-ports
[17:24:52] -!- DanielOfService has joined #archlinux-ports
[17:25:51] <tyzoid> welcome DanielOfService
[17:26:03] <DanielOfService> I'm DanielTheFox
[17:26:22] <tyzoid> ./nick ?
[17:26:25] <DanielOfService> I have been here before
[17:26:41] <DanielOfService> I just rotate nicks, but cloak is the same
[17:26:46] <tyzoid> I've been out for a few weeks, so I'm a bit out of the loop of who's been here :P
[17:27:20] <DanielOfService> heh
[17:27:35] <DanielOfService> something nice about Linux
[17:27:44] <DanielOfService> is the fact they use IRC
[17:27:57] <DanielOfService> the distro makers
[17:28:01] <DanielOfService> and support people
[17:28:02] <DanielOfService> :D
[17:44:57] DanielOfService is now known as DanielTheFox
[17:45:40] -!- DanielTheFox has parted #archlinux-ports
[17:47:45] -!- eschwartz has quit [Remote host closed the connection]
[17:48:26] -!- eschwartz has joined #archlinux-ports
[18:29:04] -!- eschwartz has quit [Remote host closed the connection]
[18:30:25] -!- eschwartz has joined #archlinux-ports
[19:07:57] -!- isacdaavid has joined #archlinux-ports
[19:11:08] -!- eschwartz[m] has quit [Ping timeout: 240 seconds]
[19:11:23] -!- brtln has quit [Ping timeout: 258 seconds]
[19:21:47] -!- brtln has joined #archlinux-ports
[19:27:09] -!- deep42thought has joined #archlinux-ports
[19:33:17] -!- eschwartz[m] has joined #archlinux-ports
[20:13:02] <brtln> deep42thought: eh, going back to the keyring subject
[20:13:09] <brtln> sorry, I was on the phone during the weekend
[20:13:31] <brtln> and I can't stand phones after they lost qwerty physical keyboards
[20:14:38] <deep42thought> hmm?
[20:14:39] <brtln> what I suggested last time was a transition keyring signed by someone from Arch (let's agree to call me & team upstream from now…)
[20:14:42] <brtln> that would contain all your master keys from some date
[20:15:07] <deep42thought> yeah
[20:15:26] <brtln> let's name it archlinux32-keyring-bootstrap; then the keyring package from your repository, archlinux32-keyring, has replaces=(archlinux-keyring archlinux32-keyring)
[20:15:55] <deep42thought> I would not "replaces=(archlinux-keyring)", but yes, ok
[20:16:06] <brtln> that should minimize manual action – users transitioning need to 1) install archliux32-keyring-bootstrap 2) setup mirrors 3) -Syu
[20:16:52] <deep42thought> if users do 2) 1) 3), we could skipt to host it at some special place and just put it into our core
[20:17:22] <deep42thought> since the db is not signed, anyway, this should work
[20:17:56] <brtln> true
[20:18:18] <deep42thought> The question is, why we need archlinux32-keyring-transition in addition to archlinux32-keyring - we could just let some trustworthy source let sign archlinux32-keyring
[20:18:30] <deep42thought> e.g. City-busz
[20:18:45] <deep42thought> his build key is (currently) one of the master keys anyway
[20:20:49] <deep42thought> and since archlinux-keyring would stay installed (similar to archlinuxarm), even any arbitrary trusted user from upstream could sign our keyring-package
[20:22:17] <tyzoid> deep42thought: I'm still in favor of the transition package
[20:22:27] <tyzoid> deep42thought: It gives us more time to be able to perform the rollout
[20:22:47] <tyzoid> since we can pretty much guarantee/fix that someone who has their key in the transition package signs the keyring
[20:22:52] <tyzoid> it'll give us more flexibility
[20:23:15] <tyzoid> that way, we only need the transition package signed once, and it'll include your key, rewby's keys, and my keys
[20:23:25] <tyzoid> potentially among a few others
[20:23:41] <tyzoid> then we get that signed once in the transition package, and then we can sign the keyring package from there
[20:24:17] <deep42thought> ok, so the advantage would be, that the transition package can stay constant, even if we update the keyring package
[20:24:19] <deep42thought> right?
[20:24:30] <tyzoid> deep42thought: exactly
[20:24:34] <tyzoid> deep42thought: It remains stable over time
[20:24:48] <tyzoid> so we don't have to keep tracking down a TU asking them to sketchily sign our package
[20:25:11] <tyzoid> deep42thought: That is, assuming, the TU doesn't have their key removed from the keyring
[20:25:27] <tyzoid> We might ensure against that by having a few TU's cross-sign our one package
[20:25:35] <tyzoid> but at that point, I'm getting pedantic
[20:25:44] <deep42thought> :-D
[20:25:45] <tyzoid> The question is how stable we want the transition package
[20:25:48] <deep42thought> or paranoid ;-)
[20:25:56] <tyzoid> Probably a better word
[20:26:19] <tyzoid> look at the english-is-my-second-language member telling a native english speaker a better word :)
[20:26:31] <tyzoid> lol
[20:26:52] <tyzoid> but yeah, we should have some sort of threshold set for what we require in terms of stability of that package.
[20:27:10] <tyzoid> Do we want to say that we only will support the transition package for a year? 6mos? 3mos?
[20:27:24] <deep42thought> I would let it install all current master and build keys, so we would only need to ensure in future that either you or I sign the archlinux32-keyring package
[20:27:33] <tyzoid> after a certain point, it becomes difficult to transition given the sheer number of packages needed to update.
[20:28:00] <deep42thought> well, pacman -Syu simply throws a lot more errors and questions, then ;-)
[20:28:10] <deep42thought> including one about unkown signatures
[20:28:11] <deep42thought> ...
[20:28:13] <tyzoid> deep42thought: That's what I'm saying
[20:28:37] <tyzoid> at a certain point, is it really worth trying to support a transition package a year out when the user is going to have to manually deal with things anyway?
[20:28:41] <deep42thought> so, november 2018 should be fine
[20:28:45] <tyzoid> sounds good
[20:29:02] <tyzoid> We should probably get two TU signatures on the transition package in case, then.
[20:29:17] <tyzoid> that should pretty much guarantee that at least one will still be valid
[20:29:32] <deep42thought> yes
[20:29:37] <deep42thought> but first, we need a package ;-)
[20:29:58] <tyzoid> deep42thought: Can we just promote the current archlinux32-keyring to the transition package?
[20:29:58] <deep42thought> any objections regarding putting it to core?
[20:30:04] <tyzoid> deep42thought: None from me/
[20:30:15] <deep42thought> I would like it to locally sign the current build keys as well
[20:30:26] <tyzoid> deep42thought: The transition package?
[20:30:30] <deep42thought> yes
[20:30:33] <tyzoid> doesn't archlinux32-keyring already do that?
[20:30:36] <deep42thought> no
[20:30:42] <deep42thought> it only signs the master keys
[20:30:53] <deep42thought> at least, that's what I think it does
[20:31:02] <tyzoid> I thought it imported all dev keys
[20:31:12] <deep42thought> import != sign
[20:31:13] <tyzoid> besides, what difference would that make?
[20:31:25] <deep42thought> the chain of trust may be only 2 levels deep
[20:31:32] <tyzoid> All of the dev keys signed by the master key would still be valid, right?
[20:31:43] <deep42thought> local key -(signed)-> master key -(signed)-> build keys -(signed)-> packages
[20:31:46] <tyzoid> you, city, and poli should all be good
[20:31:48] <tyzoid> plus mine, right?
[20:32:01] <deep42thought> no, if we exchange the master keys, they wouldn't be valid anymore
[20:32:49] <tyzoid> not sure what you mean there
[20:33:06] <deep42thought> maybe I'm wrong again
[20:33:11] <tyzoid> if you're saying that archlinux32-keyring only signs the master key, then we should be fine doing that the transition
[20:33:21] <tyzoid> because all packages are valid after archlinux32-keyring is installed
[20:33:30] <deep42thought> you're right
[20:33:39] <tyzoid> so any current signing keys should be valid after we install the transition
[20:33:43] <deep42thought> we basically need to install a (probably old) archlinux32-keyring package
[20:33:52] <tyzoid> deep42thought: Or even the current one, no?
[20:34:01] <deep42thought> the _now_ current one
[20:34:11] <tyzoid> deep42thought: Right
[20:34:17] <tyzoid> It'll be old relative to the future :)
[20:34:44] <deep42thought> and only these packaging keys which are valid now, will be valid in the future if only the transition package is installed
[20:34:53] <deep42thought> but that should be fine
[20:35:01] <deep42thought> (since I don't plan on changin mine)
[20:35:13] <tyzoid> ours are valid for two years, right?
[20:38:24] <deep42thought> yes
[21:02:20] <deep42thought> is it possible to sign a package with multiple keys?
[21:04:41] <eschwartz> I don't see why not, it's a detached sig. But you can only store one sig at a given URL path.
[21:05:12] <deep42thought> you can even store it in one file
[21:05:23] <deep42thought> at least for clear text signatures
[21:05:34] <eschwartz> Well, you can do that too.
[21:05:51] <eschwartz> Not with makepkg/makechrootpkg tooling but it's easy to do afterward
[21:05:59] <eschwartz> Not sure how repo-add handles that
[21:06:04] <deep42thought> I sign manually, anyway
[21:06:16] <deep42thought> I'll open a bug for it ;-)
[21:17:10] <eschwartz> first check if it works!
[21:17:36] <deep42thought> yeah, I meant I'll open a bug if it doesn't
[21:19:58] <eschwartz> repo-add checks that the total signature filesize in bytes is <= 16384 or raises an "Invalid package signature file" error
[21:20:33] <eschwartz> No idea what pacman thinks if it sees one despite all that.
[21:20:55] <tyzoid> eschwartz: Perhaps just an interesting thought
[21:21:07] <tyzoid> if we have reproducable builds
[21:21:15] <tyzoid> then independent builds of the same source will be the same
[21:21:31] <tyzoid> so if we have multiple builders each sign their packages, then identical packages will have multiple signatures
[21:22:07] <tyzoid> might be able to do something interesting with that
[21:22:32] <eschwartz> I don't actually know what that check is about, since package signatures seem to average 600 bytes?
[21:23:05] <tyzoid> eschwartz: It's probably to make sure someone doesn't accidently upload a fully contained non-detached signature as the sig
[21:23:06] <deep42thought> I think it tries to revoke '-a' signatures
[21:23:22] <deep42thought> ah, no this doesn't make sense
[21:23:39] <deep42thought> even an armoured sig should be <32k
[21:23:49] <deep42thought> meant <16k
[21:24:36] <tyzoid> I'd expect armoured sigs to have at most 1.5x the size
[21:24:53] <tyzoid> since it's just a base64 with an ascii header/footer
[21:25:04] <deep42thought> sry, I just though, I had read something like that in the source code
[21:25:11] <deep42thought> but you're right :-)
[21:25:18] <tyzoid> yeah, no problem.
[21:25:39] <tyzoid> Part of it is I'm also verifying my internal assumptions of the systems
[21:25:54] <eschwartz> So repo-add should be fine I suppose, I still don't know how pacman's parsing via gpgme handles things
[21:26:55] <eschwartz> It might barf on seeing too many fields or who knows what
[21:29:01] <deep42thought> so, the signature in the package db is ~twice as long as usual (so it seems to enter the db)
[21:29:59] <deep42thought> pacman fails, because one of the keys is unkown trust
[21:30:07] <deep42thought> (which it is)
[21:30:26] <eschwartz> makes sense
[21:30:43] <eschwartz> so double the chance to fail, no benefit?
[21:30:47] <eschwartz> !win
[21:30:49] <phrik> https://i.imgur.com
[21:31:08] <deep42thought> dunno, I'll try the keys in different order, now
[21:31:57] <deep42thought> still complains
[21:32:11] <deep42thought> so, yes: double the pain, no gain
[21:33:51] <deep42thought> maybe, it's a valid feature request, to accept one signature with a trusted key?
[21:34:03] <deep42thought> but on the other hand: Who needs that?
[21:34:31] -!- isacdaavid has quit [Ping timeout: 240 seconds]
[21:34:43] -!- isacdaavid has joined #archlinux-ports
[21:45:48] <tyzoid> deep42thought: Us, apparantly?
[21:46:00] <deep42thought> I'm not sure
[21:46:04] <tyzoid> deep42thought: It's potentially useful for packages that need to have long shelf-lives
[21:46:17] <deep42thought> we could just store distinct signatures and exchange them, once one gets invalid
[21:46:36] <tyzoid> or even if we wanted to implmenent a system where core files need two sigs
[21:46:39] <tyzoid> like the linux kernel, for ex
[21:46:52] <deep42thought> thinkable
[21:47:05] <deep42thought> but how would one specify which packages need two signatures?
[21:47:09] <tyzoid> imagine if we have a linux-lts package?
[21:47:13] <tyzoid> deep42thought: Good question
[21:47:14] <deep42thought> this would add another layer of complexity
[21:47:18] <tyzoid> I'm just spouting ideas here
[21:47:22] <deep42thought> :-)
[21:47:31] <tyzoid> deep42thought: But just think about a linux-lts package?
[21:47:37] <tyzoid> wouldn't we want that to be shelf-stable?
[21:47:57] <deep42thought> you could even specify in pacman.conf that you wanted 2 (or more) valid signatures before you trust a package
[21:48:07] <tyzoid> esp. as many of our 32bit users are embedded, and wouldn't want to do kernel upgrades every time
[21:48:22] <deep42thought> hmm
[21:48:27] <tyzoid> deep42thought: That could work on a repo level, like 2+ sigs needed for core
[21:48:55] <deep42thought> but I guess, no one would really need it
[21:49:02] <deep42thought> except really paranoid people - like me
[21:49:40] <tyzoid> deep42thought: Perhaps that guy on our mailing list a few months back that was doing locomotive controllers might want the extra peace-of-mind :P
[21:50:56] <deep42thought> I would _definitely_ use it
[21:51:33] <tyzoid> deep42thought: At that point, then
[21:51:37] <tyzoid> we have the logistical question
[21:52:00] <tyzoid> how would we be able to actually do the signing/verification if we don't necessarily have reproducable builds?
[21:52:16] <deep42thought> reproducible builds is a necessity
[21:52:23] <tyzoid> deep42thought: Have we done any testing as to whether the builds are reproducable?
[21:52:32] <deep42thought> otherwise people would need to sign packages they have not built
[21:52:48] <deep42thought> I think, someone said they weren't, but they're lookin at it
[21:53:22] <deep42thought> because I first wanted to use boinc's approach: let it build on multiple slaves and if it's the same everywhere, sign it with a key only on the master
[21:53:57] <tyzoid> deep42thought: Perhaps we could have a reproducable repo?
[21:54:23] <tyzoid> deep42thought: Every build-slave signs their own packages, but those that are common will automagically have duplicate sigs with different keys
[21:54:34] <tyzoid> thus allowing us to automatically enforce the requirement where able.
[21:54:47] <deep42thought> what do we do if it's different?
[21:54:55] <tyzoid> not include it in the reproducable repo
[21:55:07] <tyzoid> it'll be like testing - it's an optional repo that grants additional peace of mind
[21:55:16] <deep42thought> hmmm
[21:55:54] <tyzoid> again, just spouting ideas, but I think it could be cool
[21:56:07] <deep42thought> yeah, definitely
[21:56:35] <deep42thought> but I think, we should get at least one successful build per package, before we consider building each package again and again ;-)
[21:56:55] <tyzoid> deep42thought: definately focus on basics first :P
[21:57:14] <tyzoid> deep42thought: But I think it would be useful to have the multiple-sigs patch for pacman in so we can use it for our transition
[21:57:37] <tyzoid> ideally it'd have two modes: all-sigs-valid, and any-sig-valid
[21:57:58] <tyzoid> potentially a third: n-sigs-valid: n
[21:58:59] <eschwartz> meanwhile, file a feature request and mention it has implications for reproducible builds...
[21:59:09] <deep42thought> sound sane
[21:59:12] <eschwartz> We are already accepting SOURCE_DATE_EPOCH patches after all
[22:00:48] -!- isacdaavid has quit [Quit: isacdaavid]
[22:01:55] <tyzoid> deep42thought: Can you handle the feature request?
[22:02:08] <tyzoid> I'm unfamiliar with the process for that sort of thing
[22:03:05] <deep42thought> yeah, I can do
[22:04:29] <tyzoid> sweet :)
[22:04:43] <deep42thought> eschwartz: does it have implications for reproducible builds?
[22:04:59] <deep42thought> It's just nice together with reproducible builds, afaikt
[22:05:16] <deep42thought> (ignore the abbreviation, it's wrong)
[22:05:23] <tyzoid> deep42thought: Yes, it does
[22:05:47] <tyzoid> The implication is that if a build is reproducable, then it can be automatically rejected if there are conflicts
[22:05:54] <eschwartz> deep42thought: sure it has implications, not in the building, but in the distributing
[22:06:03] <tyzoid> because then there wouldn't be the required number of signatures to validate the package
[22:06:12] <tyzoid> It's a trust thing
[22:06:28] <eschwartz> we build reproducible packages, sign them, and use "signed by n" to prove they were reproducible
[22:06:44] <tyzoid> so if we have two packages that have the same version, one has 4 sigs, and the other only has 1, then it can be verified
[22:06:58] <tyzoid> +1 to eschwartz for brevity
[22:07:30] <deep42thought> ah, for "testing reproducibility"
[22:07:33] <deep42thought> hmm, ok
[22:07:50] <tyzoid> deep42thought: Not even testing, the package manager itself can reject builds that cannot be verified
[22:09:03] <eschwartz> (And then it becomes a matter of switching to the reproducible repos, which contain the same packages but with more appended signatures in *.pkg.tar.xz.sig and compiled into the database, and pacman enforces our level of "want reproducible")
[22:09:27] <tyzoid> ^
[22:10:03] <eschwartz> and as a bonus, pacman accepts our multiply-signed transition package so people can transition in 5 years from now, though they will have lots of trouble with migration instead :D
[22:33:22] <deep42thought> another good news: signatures can simply be concatenated by "cat"
[22:41:40] <deep42thought> !bug 54854
[22:41:41] <phrik> http://bugs.archlinux.org
[22:45:24] -!- AstroSnail has quit [Remote host closed the connection]
[23:05:28] -!- Foxboron has joined #archlinux-ports
[23:49:01] -!- deep42thought has quit [Quit: Leaving.]
[23:50:02] -!- isacdaavid has joined #archlinux-ports