#archlinux32 | Logs for 2018-07-09

[05:48:02] -!- isacdaavid has quit [Quit: Leaving.]
[06:44:21] -!- deep42thought has joined #archlinux32
[06:44:22] <buildmaster> Hi deep42thought!
[06:50:08] -!- buildmaster has quit [Remote host closed the connection]
[06:52:12] -!- buildmaster has joined #archlinux32
[07:16:43] <deep42thought> systemd is great: https://github.com - it made "pacman -Syu" fail to access /boot, print a warning (!) about not being able to write the new kernel but otherwise succeed
[07:16:45] <phrik> Title:Systemd is constantly unmounting my /boot partition · Issue #1378 · systemd/systemd · GitHub (at github.com)
[07:16:52] <deep42thought> let's hope, the master mirror comes back on again
[07:16:56] <deep42thought> cu, titus_livius
[07:20:50] -!- titus_livius has joined #archlinux32
[07:25:25] -!- deep42thought has quit [Quit: Leaving.]
[07:27:37] -!- Polichronucci has quit [Ping timeout: 244 seconds]
[07:29:44] <elibrokeit> deep42thought: use grub, don't use some badly-designed and badly-implemented FAT filesystem as the backing store for /boot, and it's fine to only mount it during the actual UEFI boot process
[07:29:58] * elibrokeit loads kernel from btrfs /
[07:39:02] -!- rcf has quit [Quit: WeeChat 2.0.1]
[07:42:01] -!- rcf has joined #archlinux32
[08:26:23] -!- Polichronucci has joined #archlinux32
[08:28:56] -!- deep42thought has joined #archlinux32
[08:28:56] <buildmaster> Hi deep42thought!
[08:30:37] <ahuillet> deep42thought : is it you who has a script that checks /lastsync and /archisos every 5 minutes?
[08:30:57] <ahuillet> /lastsync over ipv4, /lastsync and /archisos over ipv6
[08:31:09] <deep42thought> the latter, probably
[08:31:15] <deep42thought> let me check the details
[08:31:18] <ahuillet> both really
[08:31:37] <deep42thought> yes, exactly
[08:31:42] <ahuillet> https://pastebin.com
[08:31:43] <deep42thought> the ipv6 connection, most probably
[08:31:44] <phrik> Title: - - [09/Jul/2018:05:40:07 +0200] "GET /lastsync HTTP/1.1" 200 404 - Pastebin.com (at pastebin.com)
[08:32:20] <deep42thought> oh, yes, ipv4, too
[08:32:23] <deep42thought> I forgot about that
[08:32:30] <deep42thought> is that an issue?
[08:32:35] <deep42thought> should I decrease frequency?
[08:32:35] <ahuillet> no, I was just curious
[08:33:15] <deep42thought> that's the buildmaster which generates the mirror statistics
[08:33:27] <ahuillet> if you're touching mirrorlist, please remove the roelf.org mirror that is several months outdated
[08:33:43] <ahuillet> it stung me a few times.
[08:34:11] <deep42thought> ahuillet: I've done so
[08:34:16] <deep42thought> ahuillet: you may also want to set your server to listen on pool.mirror.archlinux32.org
[08:34:28] <deep42thought> which is a pool of all mirrors for simple load balancing
[08:34:51] <ahuillet> is it round robin DNS? so I need a virtualhost and that's it?
[08:35:04] <deep42thought> yes
[08:35:14] <ahuillet> let me try
[08:36:45] <deep42thought> ah, your mirror is not being included in pool, because you do not sync isos
[08:37:09] <ahuillet> let me fix that then
[08:38:30] <ahuillet> as for pool.mirror.archlinux32.org,u
[08:38:41] <ahuillet> how does the SSL certificate work in this case?
[08:38:58] <deep42thought> ah, it's http only
[08:46:13] <ahuillet> isos added, ServerAlias added. I don't know how to test that the mirror is responding to pool.mirror.archlinux32.org, but I think it should be doing that now.
[08:46:37] <deep42thought> you can test with an entry in /etc/hosts on your client
[08:49:53] <ahuillet> looks good
[08:49:58] <deep42thought> :-)
[08:50:00] <deep42thought> thanks!
[08:50:05] <ahuillet> np
[09:26:36] -!- eduardoeae has quit [Ping timeout: 268 seconds]
[10:33:58] -!- feklee has joined #archlinux32
[10:39:45] <feklee> Cannot boot from an 8 GiB USB stick on my ThinkPad T41. Is it the USB stick, the ThinkPad, or me?
[10:40:09] <feklee> (boots fine on a ThinkPad T420s)
[10:42:14] <deep42thought> the t420 is 64 bit, right?
[10:42:30] <deep42thought> which iso are you using?
[10:50:28] <feklee> Yes, T420 is 64 bit. T41 is 32 bit, 1st gen. Intel Pentium M (Banias Centrino).
[10:51:03] <feklee> @deep42thought Image that I used is: archlinux-2018.07.01-i686
[10:52:49] <deep42thought> any specific error?
[10:53:38] <deep42thought> we had some issues with the iso since march, maybe you're affected, too - you could try the february iso from https://archive.archlinux32.org
[10:53:40] <phrik> Title:Index of /isos (at archive.archlinux32.org)
[10:56:16] <feklee> The USB drive simply is not shown as boot option. It's enabled in the BIOS. So I assume one of: 1. USB drive is not compatible with the T41, or 2. the boot loader is not compatible (no idea if that's possible).
[10:57:10] <deep42thought> my experience is, that 2 is not possible
[10:57:21] <deep42thought> so I guess, your usb stick is not compatible
[10:57:27] <deep42thought> have you tried a different usb port?
[10:57:35] <feklee> yes, no difference
[10:58:03] <deep42thought> can you try a different usb stick (w/o archlinux32, for a start)
[10:58:08] <deep42thought> ?
[11:04:15] <feklee> Have to buy one first.
[11:04:32] <deep42thought> ah, hmmm
[11:05:20] <deep42thought> my guess is that either the usb stick is really not somehow compatible or - more probably - there is some config in the bios wrong
[11:05:31] <ahuillet> if you try another USB stick, try a small one, not a big one
[11:05:40] <ahuillet> I mean < 4GB... just in case. :)
[11:05:41] <deep42thought> usb sticks tend to turn up as all kind of crazy usb storage media
[11:27:59] <feklee> @deep42thought Now also tried with the February image, but no success. Seems like the USB stick is not recognized by the BIOS. In the boot list, it appears as: `-USB HDD` I now read that, if it is recognized, it should appear as: `+USB HDD`
[11:28:27] <deep42thought> ok
[11:28:47] <deep42thought> did you find any hint what kind of usb stick to buy, that would work?
[11:28:54] <deep42thought> or will you just challenge your luck?
[11:42:35] <feklee> No idea yet.
[14:27:29] -!- wreo has quit [Read error: Connection reset by peer]
[15:05:40] -!- eduardoeae has joined #archlinux32
[15:21:29] -!- Polichronucci has quit [Quit: ""]
[15:27:42] <tyzoid> deep42thought: We got a new contributor?
[15:27:53] <tyzoid> abaumann: need me to do anything special with the i486 vm?
[15:27:56] <deep42thought> tyzoid: what do you mean?
[15:28:07] <tyzoid> IIRC you should have access to do a hard restart on it
[15:28:11] <deep42thought> new mirror in france
[15:28:16] <tyzoid> deep42thought: I mean with ahuillet
[15:28:21] <deep42thought> yeah :-)
[15:28:34] <tyzoid> thanks for the mirror, btw
[15:28:54] <ahuillet> thanks, I'm glad to help.
[15:29:11] <ahuillet> I still have 3 eeePCs, at least one of them actively used, so archlinux32 matters to me.
[15:29:17] <tyzoid> :)
[15:29:24] <tyzoid> deep42thought: Btw, how's PAE coming?
[15:29:46] <deep42thought> oh, I'm not working on that
[15:29:48] <deep42thought> should I?
[15:30:06] <tyzoid> Well, once PAE gets implemented, I'll migrate my laptop from x86_64 arch to arch32
[15:30:21] <tyzoid> eat-your-own-dogfood type deal
[15:30:32] <deep42thought> :-D
[15:30:54] <tyzoid> also, the -i686 only iso should fit on a CD too, in case USB boot is too new for older devices.
[15:31:15] <tyzoid> deep42thought: Other than that, no hurry on it.
[15:32:03] <tyzoid> brb, windows needs a reboot for updates :/
[15:42:47] <tyzoid> back
[15:54:49] -!- abaumann has joined #archlinux32
[15:54:50] <buildmaster> Hi abaumann!
[15:55:18] <abaumann> tyzoid: the i486 VM is fine. I have access to proxmox and can hard trigger the VM, if necessary, no problem :-)
[15:55:23] <abaumann> that's what I did, actually.
[15:56:12] -!- abaumann has quit [Client Quit]
[16:27:02] <deep42thought> there are several things in linux-pae which cannot be compiled as modules O.o
[16:27:16] <deep42thought> nf_tables_* is only y/n, but not m
[16:52:19] <deep42thought> I encourage everyone intending to use linux-pae to test and have a look at the config: https://git.archlinux32.org
[16:52:21] <phrik> Title:archlinux32/packages: Package customizations and pure-i686 packages - Archlinux32 Gitea (at git.archlinux32.org)
[16:52:30] <deep42thought> package should be built soonish
[16:53:31] <deep42thought> I have to go now
[16:53:33] -!- deep42thought has quit [Quit: Leaving.]
[18:08:22] -!- deep42thought has joined #archlinux32
[18:08:22] <buildmaster> Hi deep42thought!
[18:08:29] <tyzoid> wb
[18:08:38] <deep42thought> Hi tyzoid
[18:11:06] <deep42thought> linux-pae just entered [staging]
[18:16:26] <deep42thought> we need to set up something which watches the version, though
[18:22:05] <deep42thought> I was thinking, if we might want to set up a "devops" repository or something
[18:22:17] <deep42thought> because not all the stuff I put in releng really belongs there
[18:22:46] <deep42thought> a version-watch-script would also be a candidate for devops
[18:32:51] <tyzoid> why not build-support?
[18:33:18] <tyzoid> or releng?
[18:33:19] -!- abaumann has joined #archlinux32
[18:33:19] <buildmaster> Hi abaumann!
[18:33:24] <tyzoid> wb abaumann
[18:33:50] <tyzoid> funny how you pop in to say a few words and then leave right after
[18:35:57] <abaumann> sorry. jack-in-the-box :-)
[18:37:15] <abaumann> deep42thought: I'm testing the PAE kernel on the server..
[18:38:13] <deep42thought> abaumann: you're brave
[18:38:22] <abaumann> no, my server is. :-)
[18:38:26] <tyzoid> lol
[18:38:42] <tyzoid> I'll load a VM at some point this week
[18:38:55] <abaumann> but.. good point.. keeping a rescue disk handy is not wrong..
[18:39:22] <abaumann> especially because this is a SCSI disk, no floppy, no USB, no CDROM machine. :->
[18:46:33] <abaumann> Linux eurohp1 4.17.4-1.0-pae #1 SMP PREEMPT Mon Jul 9 17:12:12 CEST 2018 i686 GNU/Linux
[18:46:50] <abaumann> nice. can even be installed in parallel to a linux/linux-lts kernel.
[18:47:05] <deep42thought> oh, nice :-)
[18:47:48] <abaumann> the only problem would be that virtualbox modules would also need a PAE version.
[18:48:23] <deep42thought> tyzoid: sry for the delay, didn't notice until now, that you commented on my comments: well, build-support and releng are package repositories
[18:48:29] <deep42thought> I was thinking of git repositories
[18:48:30] <abaumann> ah, just reinstalling the dkms version should work.
[18:49:59] <deep42thought> I got an answer from spi (Martin Michlmayr): "Hi Erich, I think SPI can provide the services you requested since it seems you don't need much. I can draft a resolution for the August meeting offering you to become an SPI associated project. Martin"
[18:51:02] <abaumann> Oh. This would be cool. :-)
[18:53:17] <deep42thought> yeah, I mentally cancelled this already, because it hit a 1-month timeout
[19:17:53] <tyzoid> deep42thought: What were the "requested services" again?
[19:18:05] <tyzoid> Just an account with a donation page?
[19:18:48] <tyzoid> deep42thought: We also have the releng git repo...
[19:19:04] <tyzoid> unless there's a reason you don't want to use that.
[19:19:40] <deep42thought> yeah, only financial services for now
[19:19:52] <deep42thought> yes, the git releng is where I currently put everything
[19:20:01] <deep42thought> but I have the feeling, that not everything belongs there
[19:20:16] <deep42thought> e.g. I wanted to put my ddns update script somewhere
[19:20:24] <deep42thought> but it's not really "releng"
[19:21:42] <tyzoid> ddns? for which domain?
[19:22:38] <tyzoid> deep42thought: Btw, any opposition to including the IP address in the auth token hash?
[19:22:51] <tyzoid> It does mean that sessions would invalidate upon changing networks
[19:23:01] <tyzoid> but prevents token stealing by subdomain services
[19:24:05] <tyzoid> it would require sending the requesting IP as well as the token when verifying the tokens tool.
[19:24:08] <tyzoid> too*
[19:24:09] <deep42thought> pool.mirror.archlinux32.org -> pool32.ddns.eckner.net
[19:24:14] <deep42thought> yeah, including ip is fine
[19:24:26] <tyzoid> Even with the API change?
[19:24:36] <deep42thought> api change?
[19:24:59] <tyzoid> yeah, the API to verify a token would change slightly
[19:25:07] <deep42thought> ah, np
[19:25:09] <tyzoid> since you'd need to send the originating IP address along with the token
[19:25:13] <deep42thought> we don't use that api yet :-)
[19:25:20] <tyzoid> IIRC you do on buildmaster
[19:25:45] <deep42thought> ah, that doesn't count :-)
[19:26:08] <tyzoid> I'd need to see if that would break bbs, though.
[19:26:45] <deep42thought> how should/would I specify the ip?
[19:27:00] <tyzoid> Either as a separate arg, or concatenate to the token
[19:27:15] <tyzoid> it does get hairy on dual ipv4/ipv6 clients
[19:27:29] <deep42thought> yeah
[19:27:58] <deep42thought> maybe user agent is better?
[19:28:05] <deep42thought> but also less secure ...
[19:28:10] <tyzoid> User agent is easily spoofed
[19:28:23] <tyzoid> also, is captured by the services that would do the spoofing
[19:28:39] <tyzoid> I could mitigate the need to constantly re-enter passwords by tying a cookie to just accounts.archlinux32.org with some information required to reverify the token
[19:28:42] <deep42thought> what service would do spoofing?
[19:28:56] <tyzoid> pool.mirror.archlinux32.org, for ex
[19:29:01] <tyzoid> that was the one you had concerns with
[19:29:21] <tyzoid> tying the cookie to an IP would prevent them from using a captured token
[19:29:22] <deep42thought> and how would buildmaster.archlinux32.org get the cookie?
[19:29:36] <tyzoid> The cookie is on *.archlinux32.org
[19:29:39] <tyzoid> any domain can get it
[19:29:44] <tyzoid> subdomain*
[19:30:09] <tyzoid> buildmaster would send the token as it does currently, but also send the IP address of the client making the request
[19:30:23] <deep42thought> can't you tie the cookie to one ipv4 and one ipv6 address?
[19:30:46] <tyzoid> Then I'd need to store two hashes in the cookie
[19:30:54] <tyzoid> and validate on either suceeding
[19:30:55] <deep42thought> if the cookie is tied to accounts.archlinux32.org, then buildmaster won't be able to get it
[19:31:02] <tyzoid> No, the reauth cookie
[19:31:02] <deep42thought> yeah?
[19:31:05] <deep42thought> ah, ok
[19:31:42] <deep42thought> what's the problem with two hashes?
[19:31:44] <tyzoid> i.e. if a user changes networks, then the reauth cookie contains some client-specific information which allows the generation of a new valid auth token on a new ip
[19:31:59] <tyzoid> problem of changing the hash period is it messes with BBS's cookies
[19:32:09] <tyzoid> since it's essentially re-using bbs's cookies for the system
[19:32:14] <deep42thought> we should not do the reauth cookie thing, I guess
[19:32:23] <tyzoid> reauth cookie doesn't affect bbs
[19:32:24] <deep42thought> ah, hmmm
[19:32:33] <deep42thought> but reauth sounds insecure
[19:32:34] <tyzoid> since it only touches accounts.archlinux32.org
[19:32:42] <tyzoid> How so?
[19:32:56] <tyzoid> The cookie would be set to http-only secure-only on accounts.archlinux32.org
[19:33:00] <tyzoid> meaning no other hosts would see it
[19:33:07] <deep42thought> how is "client changes ip intentionally" differentiated from "other ip hijacked cookie"
[19:33:08] <deep42thought> ?
[19:33:54] <tyzoid> Common case is user switching between networks. Esp, on mobile between wifi and cellular data
[19:34:18] <deep42thought> yeah, I understand the scenario, where you'd use it
[19:34:35] <deep42thought> but how would you know that not another one hijacked the session
[19:34:38] <tyzoid> So essentially, having the IP changed would cause the global token to invalidate
[19:34:46] <deep42thought> yes
[19:34:54] <tyzoid> so the service that needs auth would see it's a guest account, then send back to accounts.archlinux32.org for re-auth
[19:35:07] <tyzoid> accounts.archlinux32.org would see it's just an IP change on an otherwise valid token
[19:35:16] <tyzoid> and since it's got the info from the cookie, it can create a new token
[19:35:19] <tyzoid> then redirect back
[19:35:31] <tyzoid> no other service would see the contents of that reauth cookie
[19:35:41] <deep42thought> what is "an otherwise valid token"
[19:36:04] <tyzoid> an otherwise valid token == if the only thing that invalidates the token is an IP change
[19:36:23] <deep42thought> what else is stored in the token?
[19:36:36] <tyzoid> there's a few things hashed with an hmac
[19:36:46] <tyzoid> User ID is one
[19:36:51] <deep42thought> which is client-specific and non-hijackable?
[19:36:52] <tyzoid> there's the user's password
[19:37:05] <tyzoid> so if the user resets their password, then all auth tokens get invalidated
[19:37:31] -!- isacdaavid has joined #archlinux32
[19:37:34] <deep42thought> e.g. scenario: a has valid token, b sees the cookie, claims to be a (but has different ip)
[19:37:37] <tyzoid> the token itself is hijackable, but only the ID field is left in clear, IIRC.
[19:37:39] <deep42thought> how would you know?
[19:38:09] <tyzoid> "B sees the cookie, claims to be A". How would this claim work?
[19:38:12] <deep42thought> my concern is, that you basically loose the security of having the ip address in the token
[19:38:40] <tyzoid> From my perspective there's 4 parties.
[19:39:00] <tyzoid> A = Auth Server, B = Service, C = User, D = malicious server
[19:39:10] <tyzoid> D has C's token.
[19:39:19] <tyzoid> How would such an attack work, from your perspective
[19:39:38] <deep42thought> If I have the token, then I simply insert the cookie in my browser and voila
[19:39:49] <tyzoid> Your IP is different, so it won't be valid
[19:40:03] <deep42thought> you'll think it's a network change only
[19:40:14] <tyzoid> You're missing the reauth cookie
[19:40:20] <tyzoid> it won't validate as a network change
[19:40:35] <deep42thought> I use the "old" cookie for B, which reauthenticates, because the ip is invalid
[19:40:38] <deep42thought> and you revalidate
[19:40:47] <deep42thought> why won't it validate?
[19:41:02] <deep42thought> ("you" = A)
[19:41:19] <tyzoid> It requires the secret Auth-only revalidation cookie, which is set at the accounts.archlinux32.org subdomain
[19:41:30] <tyzoid> meaning that no other server than mine gets sent that cookie
[19:41:34] <tyzoid> so it shouldn't be easily captured
[19:41:53] <deep42thought> ah, ok
[19:42:13] <deep42thought> yeah, ok, sounds good
[19:42:23] <tyzoid> So sure, if you were able to obtain, or recreate the contents of that cookie, then it would be spoofable.
[19:42:56] <deep42thought> that's not my concern
[19:42:58] <deep42thought> :-)
[19:43:04] <tyzoid> The thing with the ipv4/ipv6 cookies is an annoyance from my perspective, since it means that there's potentially infinitely many valid auth tokens
[19:43:21] <deep42thought> I thought, the reauth stuff was stored on accounts.archlinux32.org, not in a cooke
[19:43:45] <deep42thought> yeah, hmmm
[19:43:48] <tyzoid> It'd have a component on both, in order to validate properly
[19:44:10] <deep42thought> just put a bogus hash in the not-yet-used ip version hash
[19:44:32] <tyzoid> i.e. hash of all 'G'
[19:44:33] <deep42thought> and when the host changes from ipv4 to ipv6 or vice versa, let the net-change reauth logic kick in
[19:44:39] <tyzoid> lol
[19:44:53] * deep42thought was serious
[19:45:02] <tyzoid> Oh, I know you were
[19:45:56] <tyzoid> other option (which might be easier) is to migrate all non-trusted service off-domain
[19:46:00] <tyzoid> idk
[19:46:38] <deep42thought> pinning the ip might be a good idea anyway
[19:46:48] <deep42thought> as ther might be some injections on trusted services
[19:46:53] <deep42thought> *there
[19:46:57] <tyzoid> Yup. I agree it's more secure
[19:47:54] <tyzoid> Hence why I was proposing it.
[19:48:34] <deep42thought> yeah, maybe just skip the ipv4/ipv6 differentiation and re-authenticate each and every time
[19:48:49] <deep42thought> when the user switches between them
[19:48:57] <tyzoid> Problem is if the user is flipping between the two
[19:49:06] <tyzoid> since it'll cause redirect loops
[19:49:12] <deep42thought> only problem I see with this is: if there's one service ipv4-only and the user prefers ipv6 on all other services
[19:49:21] <tyzoid> ^
[19:49:26] <tyzoid> hence flipping between the two
[19:49:37] <deep42thought> how does bbs handle ip switches?
[19:49:45] <tyzoid> It doesn't tack ips
[19:49:51] <tyzoid> track*
[19:49:54] <tyzoid> at least, not in the auth token
[19:50:04] <deep42thought> hmm
[19:50:05] <tyzoid> so it doesn't care. You'll stay logged in
[19:50:23] <deep42thought> grml
[19:50:36] <tyzoid> Yup, that's why I'm saying this would require code in bbs.
[19:50:46] <deep42thought> but similar problems will happen if you have multiple public ips within one ip version
[19:50:49] <tyzoid> And at that point, I might as well migrate off of using bbs cookies
[19:50:56] <tyzoid> and move it to point at accounts.arch32
[19:51:21] <deep42thought> can you make bbs authenticate against an external service
[19:51:22] <deep42thought> =
[19:51:23] <deep42thought> ?
[19:51:30] <tyzoid> That's what I'm saying.
[19:51:44] <tyzoid> I'll need to move the db from bbs and onto accounts
[19:52:12] <deep42thought> yeah, if that's feasible
[19:52:35] <tyzoid> Problem is I'm taking all the user metadata (name, website, timezone, etc.) from bbs preferences
[19:52:37] <deep42thought> sry, I'm a little distracted, there are two little guys looking at openttd here ...
[19:52:47] <tyzoid> no problem
[20:18:59] <deep42thought> otoh we're not really using the email, localization and other infos from bbs outside of the forums
[20:19:12] <deep42thought> I'm just checking for group=="Administators"
[20:19:13] <deep42thought> :-D
[20:23:52] <tyzoid> Yup. It can be useful if there's times or customizations or alert emails
[20:27:54] <deep42thought> wouldn't alert mails require it stored outside of bbs anyway?
[20:28:07] <deep42thought> because you can't expect the user to be logged in when you send the alert
[20:28:50] <tyzoid> Yes, but alert emails don't make sense if the user has never visited the service.
[20:29:17] <tyzoid> So if the user registers for alert mail, the service can store it, since they've got the email when the user is logged in
[20:29:55] <deep42thought> and when the user changes its email in bbs/accounts, the service needs to know instantly, not at the next visit
[20:29:58] <deep42thought> I'd say
[20:30:47] <deep42thought> so storing some/all information outside of bbs makes sense anyway
[20:31:44] <tyzoid> Hmm, yeah
[20:32:05] <deep42thought> but that is your decision, as I do not nearly know how much work that would be :-)
[20:35:07] <tyzoid> Yeah, it needs an overhaul internally anyway
[20:37:10] <deep42thought> bbs or accounts?
[20:46:47] <tyzoid> both
[20:46:54] <deep42thought> :-D
[20:47:00] <tyzoid> since it's piggy-backing on bbs' auth system
[20:47:10] <tyzoid> ex. You know when you send an API request to accoutns?
[20:47:17] <tyzoid> accounts*?
[20:48:21] <deep42thought> if that was a question for me to answer, I didn't undestand it :-/
[20:48:34] <tyzoid> Oh.
[20:48:53] <tyzoid> So you know how you make an api call to accounts.archlinux32.org/?token=<BLAH> when you need to verify the token?
[20:49:29] <deep42thought> yes, the buildmaster is doing it on status.php
[20:49:41] <deep42thought> e.g. https://buildmaster.archlinux32.org
[20:49:57] <tyzoid> Internally, accounts.archlinux32.org makes a very similar API call to bbs.archlinux32.org/account.php?token=<BLAH>.
[20:50:09] <deep42thought> ah, ok
[20:50:29] <deep42thought> and you basically need to reverse this?
[20:50:34] <tyzoid> Yup
[20:50:49] <tyzoid> But it requires moving lots of data around, since currently bbs is authoritative for all user data
[20:51:15] <tyzoid> which makes sense, since it's the only system set up for user registration that has all users
[20:51:40] <deep42thought> yeah
[20:51:56] <deep42thought> we'd need to run two authoritative services in parallel for some time, somehow :-/
[20:52:17] <tyzoid> Hence the overhaul
[20:57:22] <deep42thought> time for my bed
[20:57:27] <deep42thought> good night!
[20:57:30] <abaumann> cu :-)
[20:57:39] -!- deep42thought has quit [Quit: Leaving.]
[21:11:27] <tyzoid> what's this? Going to bed on time?!?
[21:11:50] <tyzoid> Quick, abaumann: We need to deliver him some pizza and caffiene.
[21:15:38] <tyzoid> Hmm, I wonder if it's possible to get pizza sauce spiked with caffeine powder.
[21:15:57] <abaumann> brr.
[21:15:58] * tyzoid notes business idea for caffeinated pizza
[21:16:03] <abaumann> lol
[21:16:48] <abaumann> I never understood the idea of decafinated coffee.. just don't drink coffee then..
[21:16:59] <tyzoid> some people like the taste
[21:17:14] <tyzoid> just like how I ocassionally drink caffeine free carbonated beverages
[21:17:44] <abaumann> all this stuff wreaks havoc with my stomach. :-)
[21:17:48] <tyzoid> Hmmm
[21:17:50] <tyzoid> "The FDA is concerned about the marketing of a peanut butter, a food popular with many children, containing added caffeine."
[21:17:57] <tyzoid> Dated December 17, 2015
[21:18:20] <tyzoid> "On Tuesday December 15, 2015 the FDA sent a letter to the company, STEEM Peanut Butter, Inc., requesting they provide us with information about their use of caffeine in peanut butter."
[21:18:30] <tyzoid> "The FDA remains concerned about the increasing number of products on the market containing added caffeine and the possibility for harmful effects when multiple caffeinated products are eaten simultaneously, especially in products that are attractive to children."
[21:19:04] <abaumann> The same people are not conserned at all about added sugar and salt.
[21:19:51] <tyzoid> Well those don't have acute health issues.
[21:20:02] <abaumann> mhprhf.
[21:20:04] <abaumann> well.
[21:20:06] <abaumann> :-)
[21:20:19] <abaumann> that's what you should believe..
[21:20:46] <tyzoid> Look, as an American, I've been eating an elevated amount of salt all my life, and I've turned out fine
[21:20:58] <abaumann> You're still young. :-)
[21:21:03] <abaumann> Things tend to cummulate..
[21:21:03] * tyzoid coughs loudly
[21:21:40] <abaumann> "Sugar Coated"
[21:21:47] <tyzoid> Speaking of, I haven't had my hourly dose of high fructose corn syrup yet.
[21:21:49] <tyzoid> brb
[21:21:57] <abaumann> lol
[21:40:44] -!- abaumann has quit [Quit: leaving]