2022-05-01 11:09:40 Ariadne: I didn't actually draft anything since I didn't get a positive response if I should draft something :p 2022-05-01 11:09:41 https://paste.xinu.at/rw1NgloUYcGpFed/rst 2022-05-01 11:10:52 We included a man-page link to the version format for the alpm section so it wasnt ambigious what was meant with "version", but I couldn't find something like that for apk 2022-05-01 11:15:27 If it looks good I can add a Reviewed-by signoff and stuff. Maybe ncopa is interested as well. 2022-05-01 11:15:39 (I can also move this to a -dev channel instead of adding noise to the securty one :p) 2022-05-02 00:19:05 o 2022-05-05 04:53:01 Foxboron: looks good to me btw 2022-05-05 06:37:47 Ariadne: thanks! 2022-05-06 15:12:00 I don't think xen on edge is vulnerable https://security.alpinelinux.org/vuln/CVE-2021-28703 2022-05-06 15:12:30 "All Xen branches up to and including 4.13 are vulnerable, but only if the patches for XSA-378 have not been applied." https://xenbits.xenproject.org/xsa/advisory-387.txt 2022-05-06 15:16:45 https://git.alpinelinux.org/aports/tree/main/xen/APKBUILD#n253 2022-05-06 15:19:57 seems we just missed one number :) 2022-05-06 15:21:02 missed where? 2022-05-06 15:21:33 I don't think we missed anything in the APKBUILD under secfixes: 2022-05-06 15:21:40 if that's what you meant 2022-05-06 15:22:09 CVE-2021-28703 is not in the list 2022-05-06 15:22:49 yet you say it is patched, so, it's missing 2022-05-06 15:25:07 (I'm a bit distracted, brb) 2022-05-06 15:31:39 I read it as it (XSA-387/CVE-2021-28703) was not valid there as XSA-378 patches had been applied 2022-05-06 15:31:45 "Xen versions 4.13.4, 4.14.x and 4.15.x are not affected." 2022-05-06 17:36:23 FYI: http://lists.busybox.net/pipermail/busybox/2022-May/089671.html 2022-05-06 18:14:14 minimal: yes, this is why i want to replace busybox 2022-05-06 18:19:07 > You truly are a monster. 2022-05-06 18:56:19 Ariadne: replace with what? toybox? uutools? 2022-05-06 20:22:05 anything tbh 2022-05-07 15:14:49 bump !33751 2022-05-07 16:25:18 omni: isn't 3.12 out of support from 1st May? 2022-05-07 16:26:16 minimal: In practice it happens after the next release 2022-05-07 16:27:13 ikke: ah, was just looking at the date specified here: https://alpinelinux.org/releases/ 2022-05-07 16:27:45 Nod, to give a basic indication 2022-05-12 20:34:57 Ariadne: i feel like despairing at openssl 2022-05-12 20:34:59 https://github.com/llvm/llvm-project/issues/55255 2022-05-12 20:35:02 https://github.com/openssl/openssl/issues/18225 2022-05-12 20:35:15 tl;dr they didn't understand strict aliasing and then went for the worst fix, while libressl and boringssl did it correctly 2022-05-12 20:35:24 i really wish libressl was an option 2022-05-12 20:35:45 i'm worried about the safety of openssl 2022-05-12 21:00:05 sam_: libressl is an option as far as i'm concerned, but we need to build a coalition 2022-05-16 00:29:33 #12946 2022-05-16 00:38:07 (found when browsing through issues) 2022-05-18 11:00:16 i think freetype in v3.15 is vulnerable to CVE-2022-27405 and CVE-2022-27406, but it does not show up in https://security.alpinelinux.org/vuln/CVE-2022-27405 2022-05-18 15:36:45 ncopa: there are no CPE match rules yet on security.a.o. They were probably added later, and they are not automatically picked up (because they are not part of the new feed) 2022-05-18 15:37:15 One thing I still needed to add is a job that fetches the yearly feeds regularly 2022-05-18 19:35:57 ncopa: they now show up 2022-05-18 20:00:00 ok. good. thanks 2022-05-20 10:42:02 im working on setup-user script now and have a question about ssh key suggestion 2022-05-20 10:42:52 the idea is that once username is set (eg 'ncopa'), the scipr will prompt user to enter an ssh key or URL to ssh keys (eg https://gitlab.alpinelinux.org/ncopa.keys) 2022-05-20 10:43:26 what I would like to do is give a suggestion to URL 2022-05-20 10:44:15 so if https://gitlab.alpinelinux.org/$user.keys exists (and have keys in it), that will be the suggested/default when pressing enter 2022-05-20 10:44:53 if it does not exist or contain ssh keys it will fallback to https://github.com/$user.keys 2022-05-20 10:45:12 and if that does not exist or does not contain any keys it will not suggest anything 2022-05-20 10:46:20 but I guess suggesting ssh keys that way is a bit controversial? 2022-05-20 14:24:02 I'd say it's a bad idea if the suggestion is the default, and if there's no disclaimer/warning that it could be dangerous 2022-05-20 14:24:18 but I don't see an issue with making it an optional feature 2022-05-20 14:49:12 ok. just think it would be extremely convenient 2022-05-20 14:51:28 thank you for the feedback 2022-05-20 14:52:22 Maybe similar to the mirror selection options? 2022-05-20 14:53:15 by selecting a number? 2022-05-20 14:54:40 or maybe have a keyword. 'gh' for github, 'al' for alpine gitlab, and 'gl' for gitlab.com 2022-05-20 14:54:43 right 2022-05-20 14:55:29 something like that could work. it would not be the default 2022-05-20 14:55:59 good idea 2022-05-20 15:13:55 ncopa: there is ssh-import-id which can handle Github and Launchpad, but its not currently packaged for Alpine 2022-05-20 15:14:24 cloud-init has support for it so I had wondering in the past about packaging it 2022-05-20 15:15:39 hm 2022-05-20 15:15:54 cloud-init is a different beast 2022-05-20 15:18:28 ncopa: perhaps the cloud-init reference was confusing - I was pointing out that ssh-import-id is an existing tool to "retrieve one or more public keys from a public keyserver and append them to the current user's authorized_keys file (or some other specified file)"" 2022-05-20 15:19:02 or were you referring to download a user's own public/private keys instead of generating them locally? 2022-05-20 15:19:04 yeah. but I'm working on the setup scripts currently, which interactively sets up a user 2022-05-20 15:19:36 no, the idea is that setup-alpine (the interactive tool), will let you create a non-root user 2022-05-20 15:20:15 and make it somewhat convenient to grab the ssh keys without copy/paste from github or gitlab 2022-05-20 15:22:30 yeah, and ssh-import-id provides a mechanism to grab specified user(s) public keys from github and place them into authorized_keys, so it does some of what you mentioned 2022-05-20 15:23:13 i understand 2022-05-20 15:26:38 as it only handles Launchpad and Github then if you were to write something similar (e.g. to also support Gitlab) then if it behaved in a similar fashion that would be useful as I could modify cloud-init on Alpine to use it instead of ssh-import-id 2022-05-21 17:44:58 !34645 !34658 2022-05-21 17:46:00 the stupid OOM killer has them occationally fail 2022-05-21 17:49:19 the builds, that is 2022-05-21 17:52:59 mhm 2022-05-22 14:52:31 !34707 !34708 2022-05-22 14:53:14 [3.15-stable] the other one 2022-05-22 14:53:27 omni: I was working on nomad already, as I sent out email to become maintainer 2022-05-22 14:54:29 ah, oh, didn't see an MR 2022-05-22 14:54:51 omni: there was not a MR yet, I was working on the build last night and intending to create MR today 2022-05-22 14:55:08 so it seems there's nothing for me to do as "maintainer" 2022-05-23 15:51:02 https://gitlab.alpinelinux.org/alpine/aports/-/issues/13828 fwiw this is because clair sucks 2022-05-23 15:51:43 i have been in contact with them to improve clair 2022-05-23 19:28:37 hmm: https://security.alpinelinux.org/branch/3.16-main 2022-05-23 19:33:38 https://security.alpinelinux.org/vuln/CVE-2019-13636 patch has the secfixes data there 2022-05-23 19:33:46 so it fails to parse it for some reason 2022-05-23 19:34:17 oh, it's not available yet on secdb 2022-05-23 19:47:20 Are we affected by https://security.alpinelinux.org/vuln/CVE-2021-44038? Arch says they don't use the vulnerable systemd / spec files, so I assume the same applies to us 2022-05-23 19:53:38 Isn't `checkpath --owner quagga:quagga --directory $piddir` this bad practice? 2022-05-23 19:59:47 i think we ended up using it as an excuse in gentoo to move people to frr 2022-05-23 19:59:54 i think we were vulnerable for the same reason as you 2022-05-23 19:59:59 (checkpath usage in init script) 2022-05-23 20:00:20 https://bugs.gentoo.org/825358 2022-05-23 20:01:23 i don't think we looked into it much because quagga had a bunch of bugs and it seemed plausible the checkpath might be problematic 2022-05-23 20:01:26 so we took the excuse to move to frr 2022-05-24 08:51:57 I dont think we are affected. `checkpath --owner quagga:quagga --directory $piddir` should be safe as long as the parent directory is owned by root 2022-05-24 08:53:15 for the cve maybe, but it's terrible practice regardless 2022-05-24 08:53:41 the pidfile is set to that dir with pidfile= which means quagga can write `1` into it and you get a panic on stop 2022-05-24 08:54:53 true 2022-05-24 08:55:05 and the cve is to do with some configuration file in /etc/quagga and not the init script, no? seems slightly tangential 2022-05-24 08:55:09 yeah, there was other service that had something similar, openldap 2022-05-24 08:55:28 the pidfile should be used by root 2022-05-24 08:55:37 fwiw; we already package frr 2022-05-24 08:55:41 s/used/owned/ 2022-05-24 08:55:43 if gentoo moved to it we could technically do the same 2022-05-24 08:56:04 though it depends on Stuff and putting it also in main is not as easy 2022-05-24 08:57:07 hm, maybe 'just' libyang/rtrlib/libssh 2022-05-24 09:01:05 psykose: you are right about quagga. its vulnerable to the stupid pidfile permission issue 2022-05-24 09:01:19 they drop privileges first, and then after they write the pidfile 2022-05-24 09:02:04 https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#pid-files-should-be-writable-only-by-root 2022-05-24 09:02:10 which means an attacker can kill whatever process on quagga shutdown 2022-05-24 09:02:36 technically it's.. easily patched 2022-05-24 09:02:42 if the code is not terrible 2022-05-24 09:02:54 just write nothing, set pidfile= one dir up, and command_background=true 2022-05-24 09:02:59 if they actually do anything special though, then not 2022-05-24 09:03:33 well, you also need to keep it foreground 2022-05-24 09:04:04 but that's default anyway 2022-05-24 09:04:40 i wonder if it writes any pidfile without -d? if it doesn't then just remove it and it's fixed 2022-05-24 09:05:05 i think it does 2022-05-24 09:05:12 :) 2022-05-24 09:05:32 but actually.. no that's fine 2022-05-24 09:05:41 because we ignore it, and pidfile= can be something else and root owned 2022-05-24 09:06:49 it uses the pidfile as lock file 2022-05-24 09:07:15 sure, but does it not clean that itself 2022-05-24 09:11:15 i guess it should be renamed to lock file and placed in a user writable dir, run in foreground with command_background=true so root creates the pid 2022-05-24 09:11:37 anyway, its a different issue not the mentioned CVE 2022-05-24 09:11:41 yep 2022-05-24 09:11:55 and it could probably have its own CVE 2022-05-24 09:12:41 psykose: dmvpn uses quagga 2022-05-24 09:13:17 something like this https://img.ayaya.dev/tmmB2G2oiBgQ 2022-05-24 09:13:39 ikke: dmvpn looks even more cursed than quagga 2022-05-24 09:14:44 (and i did fuck up the --pidfile argument) 2022-05-24 17:05:16 Ariadne: https://gitlab.alpinelinux.org/ariadne/security-rejections/-/merge_requests/1 2022-05-24 23:28:29 ikke: merged