<    April 2017    >
Su Mo Tu We Th Fr Sa  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 29  
00:12 <jirutka> I’ve tries to rebuild LibreSSL 2.5.3 with reverted https://github.com/libressl-portable/openbsd/commit/ddd98f8ea741a122952185a36c1396c14c2fda74 and now all nginx tests pass! /cc ncopa
00:13 <Shiz> ...
00:13 <Shiz> this definitely seems worth SOME cve
00:13 <jirutka> yes
00:13 <jirutka> how should I proceed?
00:17 minimalism joined
00:26 <jirutka> Shiz: how about CVE?
00:30 <Shiz> i'd first bring it up on the issue in question that it may be CVE worthy as its an obvious semantics change
00:54 <Shiz> jirutka: as this bypasses the entire SSL verify mode if the callback returns success...
00:55 <Shiz> or does it
00:55 <Shiz> it's kind of hard to follow
00:56 <Shiz> jirutka: hmm actually
00:56 <Shiz> it may just be nginx tests...
01:00 robtec joined
01:09 s33se joined
01:10 <jirutka> Shiz: I’ve updated nginx bug report with more info https://trac.nginx.org/nginx/ticket/1257#comment:3
01:11 <Shiz> right
01:11 <Shiz> >Non-zero exit status: 255
01:11 <Shiz> ???
01:12 <Shiz> but yeah, looks like an nginx problem indeed
01:13 <Shiz> jirutka: i think this qualifies as an nginx CVE, probably
01:13 <Shiz> it should not by any means always return 1
01:14 czart__ joined
01:19 <jirutka> srsly, OpenBSD still use CVS? they are really masochists…
01:30 <tmh1999> kaniini : I am reading gcc APKBUILD and there is this commit : https://git.alpinelinux.org/cgit/aports/commit/main/gcc?id=3ec4774bf40a3673935c0e87c917dab70751d33a lol
01:31 <tmh1999> and right before that is the commit you added yourself about powerpc triplet lol
01:47 DLange joined
02:15 Vaelatern joined
03:04 <TemptorSent> Question - what would be the immediate feasiblity of adding the exact kernel release string to all kernel related packages in the .PKGINFO?
03:04 <TemptorSent> That would solve the ugliest problem with version not matching releases.
03:19 cyteen joined
03:25 poptart joined
03:35 <poptart> Out of curiosity how are we supposed to handle kernel modules in packages? I've tried to find some apk examples, but I think I'm just leading myself in the wrong direction
03:37 <Shiz> depends on the kernel module in question
03:37 <Shiz> what are you thinking of?
03:38 <Shiz> https://git.alpinelinux.org/cgit/aports/tree/main/xtables-addons-grsec/APKBUILD
03:38 <poptart> I'm trying to package wireguard and it compiles into a .ko or dkms
03:38 <Shiz> generally something like this is followed
03:39 <Shiz> the extra stuff is to ensure the package matches with the kernel ver or the build fails
03:41 <poptart> Awesome, thanks for pointing me in the right direction
03:43 <BitL0G1c> poptart - wireguard-tools / -grsec / -vanilla - already in testing
03:43 <poptart> Oh! Wonderful
03:44 <BitL0G1c> checkout 'pass' by the same author - it's great
03:44 <BitL0G1c> passwordstore.org
03:45 <BitL0G1c> see the README.alpine for making the clipboard work over ssh for root
03:45 <poptart> I'm well aware of zx2c4, he's wonderful
03:45 <BitL0G1c> yes
04:31 czart_ joined
04:45 <tmh1999> jirutka, ncopa : llvm4, spl-vanilla, zfs-vanilla all build good on my test s390x machine. So it is probably due to the builder. Hum...
05:12 fabled joined
05:35 vakartel joined
05:53 <TemptorSent> fabled ? You actually here?
06:00 <fabled> TemptorSent, yes
06:00 <TemptorSent> Hello fabled, long time no see! How are things?
06:02 <fabled> TemptorSent, okish, been doing non-alpine things for a while
06:02 <TemptorSent> fabled: Any insights as to resolving the showstopper with apk being unable to install multiple versions of the kernel in parallel?
06:02 <fabled> hope to get back on track
06:03 <TemptorSent> It's bricking systems at random for multiple people it seems, not just me.
06:03 <fabled> TemptorSent, it's a design feature that multiple version of same pkgname cannot currently co-exist
06:03 <fabled> you can have linux-vanilla and linux-grsec coexist
06:03 <TemptorSent> Yeah, which means I have an unbootable system until I go manually fix it.
06:03 <TemptorSent> My modules don't match my kernel.
06:04 <fabled> it's more of package naming then
06:04 <fabled> should maybe include version id in pkgname
06:04 <TemptorSent> kaniini was looking into that.
06:04 <fabled> and use some provides name instead
06:05 <TemptorSent> The other major issue is the design of the parser that makes it impossible to use package atoms for fetch/search.
06:05 <fabled> currently the fact that only one version of each pkgname can exist is pretty hardwired
06:05 <fabled> TemptorSent, ?
06:05 <fabled> atoms?
06:05 <TemptorSent> Yeah, 'apk search -x `apk search -x linux-grsec`'
06:06 <fabled> oh, you mean the foo-1.2-r1 format?
06:06 <TemptorSent> Yes.
06:06 <TemptorSent> The complete $pkgname-$pkgver string.
06:06 <fabled> i don't really like that format. it's sort of gentoo heritage from times before i came aboard.
06:07 <fabled> i'm planning to rework apk-tools
06:07 <fabled> though. i've been talking about that for a while and i'm now a few months late :P
06:08 <fabled> i do have some code already
06:08 <fabled> but it's still long way
06:08 <TemptorSent> Well, the problem lies in the fact that you can't fetch a package by it's complete name, so you have to strip the version and hope that what you get matches what you want, then check the version.
06:08 <fabled> yes
06:08 <TemptorSent> In the mean time, we have bjorked systems popping up.
06:08 <fabled> do you have notes, or written somewhere all the apk commands you are missing?
06:09 <TemptorSent> See: Issue #7100
06:09 <algitbot> Feature #7100: apk should support the use of full &#39;$pkgname-$pkgver&#39; atom as returned by &#39;apk search -x $pkgname&#39; everywhere &#39;$pkgname&#39; is used - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7100
06:09 <TemptorSent> Issue #7101
06:09 <algitbot> Feature #7101: Allow apk to operate on .apk FILE most places PACKAGE is specified - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7101
06:09 <TemptorSent> Issue #7102
06:09 <algitbot> Feature #7102: Information available via &#39;apk info&#39; on a package is incomplete with respect to contents of .PKGINFO. - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7102
06:10 <TemptorSent> Issue #7103
06:10 <algitbot> Feature #7103: Add ability for apk to extract files, extended headers, and metadata directly from .apks - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7103
06:10 <TemptorSent> Issue #7104
06:10 <algitbot> Feature #7104: [subset of #7103] Extract manifest of pax checksum headers vs. files for apks to stdout. - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7104
06:10 <TemptorSent> Issue #7107 is actually fixed in git now thanks to Shiz and kaniini.
06:10 <algitbot> Bug #7107: APK prints warnings and errors to STDOUT not STDERR - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7107
06:12 <fabled> Issue #7107 caused regression
06:12 <algitbot> Bug #7107: APK prints warnings and errors to STDOUT not STDERR - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7107
06:12 <TemptorSent> Those are the ones that could probably be supported with the existing apk with some reworking in the parsing for fetch/search.
06:12 <TemptorSent> What?
06:12 <TemptorSent> Having errors to stderr causes a regression?
06:13 <TemptorSent> You mean I have to go put my grep -v WARNING in every place it breaks things when it issues a spurious warning about my extra repo in the repo file and I'm on a different arch?
06:13 <TemptorSent> I'm sorry, but warnings to stdout is simply insane.
06:14 <fabled> updated https://bugs.alpinelinux.org/issues/7107
06:14 <TemptorSent> And -q will not work, since the output for apk search -x differs!
06:14 <Shiz> wut
06:15 <fabled> TemptorSent, yes, the output / certain input are not cohorent in all places. it's largely due to historical reasons
06:15 <TemptorSent> *facepalm*
06:15 <fabled> we've spoken about fixing it
06:16 <fabled> but it's been pending due to various different legacy and time allocation reasons
06:16 <Shiz> that regression seems very odd...
06:16 <TemptorSent> No kidding, I can't see what's going on there.
06:17 <fabled> i think it's some sort of stdio caching issue
06:17 <TemptorSent> The fflush should have handled that.
06:18 <TemptorSent> Oh, wait -- is apk_log_err missing a fflush call perhaps?
06:18 <Shiz> it's not, it's handled in log()
06:18 <fabled> log() does it now
06:18 <Shiz> maybe apk_progress_force should only be set in apk_log
06:18 <fabled> but what i think is one issue
06:18 <TemptorSent> Yeah, the va wrapping shouldn't change that...
06:18 <Shiz> instead of apk_log_err...
06:18 <fabled> the progress bar printing uses a sort of nasty trick
06:19 <fabled> after writing the bar
06:19 <fabled> it also puts a control sequence to the buffers
06:19 <fabled> and expects next write to go to the same FILE
06:19 <TemptorSent> Let me guess, you're resetting the line position with the escape sequence.
06:19 <TemptorSent> Why doesn't it run on a different FD?
06:20 <fabled> yes, it resets cursor
06:20 <fabled> fflush(stdout);
06:20 <fabled> fputs("\e8\e[0K", stdout);
06:20 <TemptorSent> Ug, yeah -- that would do it.
06:20 <fabled> and now that stderr, and stdout are mixed
06:20 <fabled> the control sequence is not printed
06:20 <fabled> until next regular log
06:21 <fabled> in fact
06:21 <TemptorSent> How about having the progress bar use fd3 instead?
06:21 <fabled> ?
06:21 <fabled> they all share same console
06:22 <TemptorSent> You can get a bit cute recombining them and control the fflush
06:22 <TemptorSent> Since that's what appears to be ending up out of order.
06:23 <fabled> the commands are
06:23 <fabled> "Restore cursor position and attributes" + "Clear line from cursor right"
06:23 <fabled> the idea is that it'll erase the progress bar
06:24 <TemptorSent> Right, what I mean is if you can sequence the order of the output, it will work as expected.
06:24 <fabled> so writing to stderr, should first fflush stdout
06:24 <TemptorSent> Right.
06:24 <fabled> i think adding fflush(stdout) in error logging should fix it
06:25 <TemptorSent> wrap fflush with a macro or inline so it always flushes in the right order.
06:26 <fabled> i think http://sprunge.us/eRQB should do it
06:27 <TemptorSent> You might want to put that right in apk_log
06:28 <TemptorSent> er log
06:28 <fabled> why?
06:28 <TemptorSent> Since that's wher the actual output takes place.
06:28 <TemptorSent> It will fix other such cases if they happen to exist somewhere.
06:29 <fabled> but it needs flush only when writing to stderr
06:29 <TemptorSent> That means thigns might break with interesting redirections.
06:29 <fabled> ?
06:29 <fabled> no
06:30 <Shiz> redirections manipulate the actual fds
06:30 <Shiz> so no, it won't break stuff
06:31 <fabled> the other option is http://sprunge.us/DdJc
06:31 <TemptorSent> So if the dest FD happens to be going to the console as well?
06:31 <Shiz> latter option seems better
06:31 <TemptorSent> Agreed.
06:31 <fabled> in current codebase, they do the same thing. you can call log_internal only from the two exposed functions
06:32 <fabled> but in case log_internal is ever used more, it's a bit safer
06:32 <TemptorSent> also, it looks like a length-check may be needed?
06:33 <fabled> i'll commit the latter fix then
06:33 <fabled> TemptorSent, length-check?
06:34 <TemptorSent> Buffer sizes, or is that handled a layer up?
06:34 <Shiz> what buffer sizes
06:34 <TemptorSent> format, va
06:34 <Shiz> ??
06:34 <Shiz> those aren't buffers
06:35 <TemptorSent> Ahh, const - nm.
06:36 <TemptorSent> presumably there are no copy semantics in the chain to be concerned with?
06:36 <fabled> no
06:37 <fabled> see also https://git.alpinelinux.org/cgit/apk-tools/commit/?id=517378721855280d2e23d25d7529e6b9cbae9136
06:37 <fabled> we used to log everything to stderr
06:37 <fabled> i think the primary reason for changing that was to put progress bar printing to stdout
06:37 <fabled> and to have the reset sequence cached in the FILE
06:37 <fabled> musl seems to have uncached stderr
06:38 <TemptorSent> Ahh, while stdio is buffered io
06:38 <fabled> yes
06:38 <fabled> stdout is line-buffered
06:38 <fabled> stderr is not buffered
06:39 <fabled> in addition to referring to different FDs
06:39 <fabled> the backing device is same (/dev/something)
06:39 vakartel joined
06:40 <TemptorSent> Right, that makes things potentially entertaining.
06:41 <fabled> yes, it's easy to mess things up unless you know the differences :)
06:41 <fabled> i think glibc somehow synchronizes stdout/stderr different
06:41 <fabled> musl is a bit more explicit on it
06:41 <TemptorSent> Would it be possible to do the progress bar with line-updates and just treat it as a single operation each call?
06:42 <fabled> could use ncurses or similar
06:42 <TemptorSent> That's probably getting heavier than necessary for a simple progress bar :)
06:42 <fabled> but wanted to keep that dependency out
06:43 <TemptorSent> The escape codes should work, you'd just need to update the buffer and rewrite the entire line with each call.
06:43 <fabled> yes, the "hack" just allows not keeping any state
06:44 <TemptorSent> Yeah, you'd need to count output lines otherwise or pick an absolute position
06:45 <TemptorSent> vt102 based, right?
06:45 <fabled> iirc, it's ansi escape sequence which should be supported in most term flavors
06:46 <TemptorSent> Right, vt100/vt102
06:50 <TemptorSent> you could probably use the esc-7 sequence and esc 8 sequences together to make it work.
06:51 <TemptorSent> On any other output, send esc-7, then have the esc-8 in the progress bar line.
06:53 <TemptorSent> Either that, or just directly set it using esc [ h
06:54 <TemptorSent> Anyway, all that aside -- is it possible to accept the $pkgname-$pkgver string as valid input and pass it to the dep parser in a format that will get the correct packge or fail?
06:57 <TemptorSent> fabled: Also, kaniini's suggested solution for kernel package naming is something to the effect of $pkgname-$kver-$pkgver, making the actual package name '$pkgname-$kver' and allowing multiple versions to be installed while still being tracked by apk for the minor version
06:58 <TemptorSent> actually s/$kver/$krel/g
07:00 <TemptorSent> We want the exact release string from the kernel in the package name, otherwise we don't know the real kernel release string until we download the kernel and extract /usr/share/kernels/*/kernel.release
07:01 <TemptorSent> This gives us 'linux-grsec-4.9.22-0-grsec-4.9.22-r0' and 'linux-vanilla-4.9.22-4.9.22-r0' for instance.
07:03 <TemptorSent> (but sometimes it's 'linux-vanilla-4.9.22-0-4.9.22-r0', just to keep life interesting)
07:15 royger joined
07:41 t0mmy joined
08:09 fekepp joined
08:44 <ncopa> royger: i have a question on xen network setup
08:45 <ncopa> currently our alpine-xen iso will suggest a br0 interface at install
08:45 <ncopa> is that a common way to set up xen hosts?
08:46 <ncopa> i see that lxc on ubuntu has an lxcbr0 interface for bridge of your containers
08:46 <ncopa> libvirt sets up virbr0
08:46 <ncopa> and both set up dnsmasq on it
08:46 <^7heo> ncopa: in my experience, the "common" way to set xen up isn't always the most reliable
08:46 <ncopa> so guests can get dhcp addr of the private network
08:46 <^7heo> or the simpler
08:47 <ncopa> my question is if it would make sense to set up a xenbr0 interface
08:47 <ncopa> and have dnsmasq on it
08:47 <^7heo> also it really depends on the xen version
08:48 <ncopa> i am thinking for alpine-xen-3.6
08:48 <ncopa> with xen 4.8
08:48 <^7heo> but I remember the network with Xen (on debian) as a giant pain
08:48 <ncopa> i want make it a pleasant experience on alpine
08:48 <^7heo> because of the lack of proper error reporting
08:49 <^7heo> and weird presets
08:49 <^7heo> so let's try to document that right at least
08:50 <^7heo> anyhoo, br0++
08:50 <royger> ncopa: hm, the classic Xen bridge is/was xenbr0 IIRC
08:50 <^7heo> on my side
08:50 <^7heo> yeah
08:50 <royger> but I'm not sure why all those solutions couldn't use br0 or bridge0
08:50 <ncopa> royger: and then you do port forward to the guest on the host?
08:51 <royger> ncopa: yes, default bridge is xenbr0 https://xenbits.xen.org/docs/unstable/man/xl.conf.5.html but alpine could ship a slightly custom xl.conf with a different default bridge (see vif.default.bridge="NAME")
08:51 <^7heo> nah you do routing
08:51 <ncopa> ok
08:51 <^7heo> with IP forward
08:51 <^7heo> nat is discouraged
08:51 <royger> ncopa: hm, no, I don't do that, I don't filter anything on the bridge
08:52 <^7heo> bridging/routing is cleaner
08:52 <ncopa> so routing instead
08:52 <ncopa> ok. so having an /etc/init.d/xen-net service makes sense
08:52 <royger> ncopa: the simple setup is to just add the virtual interface to the bridge and that's all.
08:52 <ncopa> which by default creates a xenbr0 interface
08:53 <ncopa> and sets up dnsmasq on it
08:54 <royger> hm, the "simple" setup would be to create a bridge and just add your primary interface to it.
08:54 <ncopa> thats what we do now
08:54 <royger> but what's the point in adding dnsmasq, do you what to provide a dns/dhcp server for the guests?
08:55 <ncopa> yes
08:55 <^7heo> yeah do not add dnsmask
08:55 <ncopa> provide dhcp for guests
08:55 <ncopa> have a guest network with dhcp
08:55 <^7heo> I would use a proper dhcpd
08:55 <royger> hm, but if a real interface is added there, isn't this going to cause issues?
08:55 <ncopa> yes
08:55 <ncopa> so the options are:
08:56 <ncopa> br0 + real interface. no dhcp service provided
08:56 <^7heo> and also, when I managed a xen network
08:56 <ncopa> xenbr0, private net, dhcp provided from dnsmasq
08:56 <^7heo> I had a script manage the IPs on the host
08:56 <^7heo> since it's all local to the host
08:56 <^7heo> no need for network protocol
08:56 <royger> ncopa: and do forwarding to the real interface from xenbr0?
08:57 <ncopa> leave that to the user
08:57 <ncopa> you can forward or route
08:57 <ncopa> or you can set up your own net the way you want. this is to have a simple default
08:57 <royger> OK, I think we should have an easy way, very easy, to allow the VMs to access the network. Or else it's goign to be a PITA for users
08:57 <^7heo> +1
08:58 <ncopa> yes
08:58 <^7heo> I would say the real show stopper is any unconfigured network setting
08:58 <royger> this is also going to be a problem for people trying to ssh or whatver into the VMs from outside the host, but maybe that's good...
08:59 <ncopa> we have 2 options to do that: 1) br0, hosts interface. real bridge. guests are on the hosts network. 2) set up a private net xenbr0 with dnsmasq
08:59 <^7heo> the farther away from what people are used to configure, the more problematic
08:59 <^7heo> 1
08:59 <^7heo> def 1
08:59 <ncopa> ok, so option 1 is the default setup
09:00 <^7heo> imho yes
09:00 <ncopa> option 2 is how lxc and libvirt set up the defaul
09:00 <^7heo> it's easier on the guests
09:00 <^7heo> (the opt 1)
09:00 <ncopa> but you normally dont run xen on a desktop
09:00 <royger> ncopa: I'm not oposed to the xenbr0 + dnsmask, but it's not common (most dristros just bridge the primary network card), and I think there needs to be a very simple way (like xenbr0.allow_network=1) or similar to allow the interfaces on xenbr0 to access the host network
09:01 <ncopa> ok
09:01 <royger> oh, didn't know libvirt did that... maybe people is used to that kind of setup then. I'm not a system administrator FWIW
09:02 <^7heo> also opt 2 is definitely doing more magic from the user pov
09:02 <ncopa> yes
09:02 <^7heo> royger: nah but libvirt isn't a good example imho
09:02 <royger> well, I don't administer *any* system at all, so my opinion here is probably pointless
09:02 <ncopa> :)
09:02 <^7heo> alpine should not strive to follow bad examples
09:02 <royger> (on purpose)
09:02 <^7heo> no matter how popular
09:03 <ncopa> ok next question
09:03 <ncopa> woudl it make sense to rename "br0" to "xenbr0"?
09:03 <^7heo> yes
09:04 <ncopa> even if host network is bridged?
09:04 <^7heo> more specific, better for inter-operability
09:04 <ncopa> ok
09:04 <ncopa> thanks for your input
09:04 <ncopa> i have a plan
09:05 <^7heo> well, people won't assume a private network and dnsmask because the bridge name is xenbr0 as opposed to br0
09:05 <^7heo> at least I hope
09:06 <^7heo> for our world
09:06 <ncopa> i will give them the option
09:06 <ncopa> both will be possible
09:06 <ncopa> both will be simple
09:06 <ncopa> when you do setup-alpine
09:06 <ncopa> it will suggest create xenbr0
09:07 <ncopa> it currently suggests br0
09:07 <ncopa> and will bridge the hosts network
09:07 <ncopa> it will continue as ususal
09:07 <ncopa> so the only change will be rename br0 to xenbr0
09:08 <ncopa> if you dont set up that on the host setup, you will still be able to: apk add xen-net
09:08 <ncopa> and /etc/init.d/xen-net start
09:08 <ncopa> which will do the xenbr0 + dnsmasq magic for you if you want that behavior
09:09 <ncopa> i will also create a similar lxc-net service
09:13 <royger> ncopa: FWIW, on FreeBSD the default is bridge0
09:13 <ncopa> ok
09:13 <ncopa> freebsd has also different network interface
09:13 <ncopa> interfaces
09:13 <ncopa> not eth0
09:13 <royger> right, but bridges can be named as you wish, xenbr, br or bridge
09:14 <ncopa> i suppose xenbr0 makes sense if xen use that as default
09:14 <royger> I just don't think the "xen" prefix adds any value to it, unless it means something for the admin
09:14 <royger> I assume Linux ppl is used to that.
09:14 <skarnet> it adds a sense of fraternity among xenbr0s
09:17 <ncopa> bridging host network is a bit annoying when you run it in vmware fusion which i used to test the alpine-xen iso
09:17 <ncopa> but i suppose thats not the common usecase
09:17 <ncopa> i had to enter password on boot to give access to promisc mode
09:21 <fcolista> if i have a mounted /media/usb and I changed the usb, how should I tell to Alpine to recheck the partition table and figure out the new size?
09:22 <fcolista> restarting modloop is not enough
09:22 <fcolista> server has an uptime of > 500 days
09:23 <fcolista> so a reboot is not doable
09:24 <ncopa> :D
09:24 <ncopa> how did you change it?
09:24 <ncopa> did you unplugged it?
09:25 <ncopa> or just resized the partition
09:25 consus joined
09:25 <fcolista> changed it
09:25 <fcolista> (wasn't me..but this is another story)
09:26 <ncopa> i think you can unmount it and unplug it physically
09:26 <ncopa> and insert it again
09:26 <fcolista> I dont' have physical access
09:26 <fcolista> :)
09:26 <ncopa> i think kernel will not use the new partition table if it was "in use" when the change happened
09:26 <ncopa> there are some command, partprobe i think
09:26 <ncopa> that might be able to do it
09:27 <clandmeter> yes 2 if i remember
09:27 <ncopa> but i dont know if you need to unmount it first
09:27 <fcolista> kpartx, partprobe o re-read the partition table
09:27 <fcolista> with /proc fs
09:27 <fcolista> one of this way i think
09:27 <fcolista> so, i shold:
09:27 consus joined
09:27 <fcolista> stop modloop
09:27 <ncopa> umount /media/usb too
09:27 <ncopa> make sure its unmounted
09:27 <fcolista> umoun /media/usb
09:28 <fcolista> re-read the partition table
09:28 <fcolista> adn then remount
09:28 <ncopa> yes
09:28 <ncopa> i think that should work
09:29 <fcolista> this does not affect what is running right?
09:29 <clandmeter> no
09:30 <clandmeter> if its a regular run from ram install.
09:30 <ncopa> depends on if you have something else mounted on the disk
09:30 <ncopa> if you have /var mounted there too then you'll have problem
09:31 <fcolista> no, var is on raid disk
09:32 <ncopa> then it shoudl be all good
09:39 <fcolista> heh
09:39 <fcolista> that's interesting
09:39 <fcolista> rc-service modloop stop
09:39 <fcolista> partx -va /dev/sda
09:39 <fcolista> rc-service modloop start <-fail
09:39 <fcolista> ls /dev/sda
09:39 <ncopa> is /media/usb mounted?
09:39 <fcolista> there's no sda1
09:39 <fcolista> no
09:40 <ncopa> fdisk /dev/sda
09:40 <fcolista> it exists
09:40 <ncopa> does it show sda1
09:40 <fcolista> Command (m for help): p
09:40 <fcolista> Disk /dev/sda: 28.9 GiB, 31009800192 bytes, 60566016 sectors
09:40 <fcolista> Units: sectors of 1 * 512 = 512 bytes
09:40 <fcolista> Sector size (logical/physical): 512 bytes / 512 bytes
09:40 <fcolista> I/O size (minimum/optimal): 512 bytes / 512 bytes
09:40 <fcolista> Disklabel type: dos
09:40 <fcolista> Disk identifier: 0x4387b4f9
09:40 <fcolista> Device Boot Start End Sectors Size Id Type
09:40 <fcolista> yes
09:40 <ncopa> ok
09:40 <fcolista> Device Boot Start End Sectors Size Id Type
09:40 <ncopa> and in /proc/partitions?
09:40 <fcolista> /dev/sda1 * 32 60565503 60565472 28.9G c W95 FAT32 (LBA)
09:41 <fcolista> yes
09:41 <fcolista> can-f1-ter-lxc-1:~# cat /proc/partitions
09:41 <fcolista> major minor #blocks name
09:41 <fcolista> 8 0 30283008 sda
09:41 <fcolista> 8 1 30282736 sda1
09:41 <ncopa> ok
09:41 <fcolista> also there
09:41 <ncopa> then: mdev -s
09:41 <ncopa> its just the node that needs be created
09:41 <fcolista> modprobe: can't change directory to '/lib/modules':
09:41 <ncopa> the devnode
09:41 <fcolista> but
09:41 <fcolista> now it exists
09:41 <ncopa> then you shoudl be able to mount /media/usb
09:41 <ncopa> and start modloop
09:41 <fcolista> yes
09:42 <fcolista> it does it work
09:42 <fcolista> bah
09:42 <fcolista> still 2GB
09:42 <fcolista> /dev/sda1 2.0G 1.9G 123.9M 94% /media/usb
09:42 <fcolista> (this is the df result9
09:43 <ncopa> partition may be bigger
09:43 <ncopa> that filesystem
09:43 <fcolista> fs is fat32
09:43 <ncopa> with ext4 you'd resize2fs after chanign partition size
09:43 <ncopa> i dont think fat has good support for resizing
09:43 <fcolista> that's not a resize
09:43 <fcolista> it's another usb pen
09:45 <ncopa> not following, was not the partition of the same usbpen modified?
09:53 vakartel joined
10:34 <ncopa> https://grsecurity.net/passing_the_baton.php
10:35 blueness joined
10:37 sigjuice_ left
10:37 <nmeum> oh wow
10:39 <ncopa> see the faq also
10:39 <algitbot> http://wiki.alpinelinux.org/wiki/FAQ
10:39 <ncopa> we need rename linux-grsec to something else
10:39 <ncopa> i suggest we rename it to linux-gsec
10:47 blueness joined
10:59 LouisA joined
11:05 <skarnet> linux-the-patch-formerly-known-as-grsec
11:10 <Shiz> ncopa: what about just -hardened
11:11 <ncopa> thats a good suggestion
11:11 <ncopa> i like it
11:11 <skarnet> there are many ways to harden a Linux
11:11 <ncopa> exactly
11:11 <Shiz> looks like PaX patches are still public, despite their FAQ... https://grsecurity.net/~paxguy1/pax-linux-4.9.24-test7.patch
11:12 <Shiz> who knows about future ones though
11:12 <ncopa> they have probably just not removed it yet
11:12 <ncopa> yes
11:12 <skarnet> better save them before they disappear :P
11:12 <ncopa> i did
11:12 <Shiz> skarnet: there's already grsec-scrape
11:12 <Shiz> :)
11:12 <skarnet> ha
11:12 <Shiz> https://github.com/slashbeast/grsecurity-scrape
11:12 <skarnet> grsec-me-harder
11:13 <ncopa> i really liked the -hardened suggestion
11:13 <ncopa> we give users a hardened kernel option
11:14 <ncopa> how we harden it may change over time
11:29 <Shiz> :)
11:31 <Shiz> ncopa: i wonder how viable it would be to coordinate with other distros (gentoo's, any others?) hardened teams on to see if there's an animo/development power for at least forward-porting the current grsec feature set to new kernels
11:31 <Shiz> it's something i'd be at least willing to put development time in
11:43 <jirutka> fabled: <fabled> i don't really like that format. – what format specifically? I hope that you don’t wanna drop Gentoo-style versioning format, I mean $pkgver part?!
11:43 <fabled> the pkgname-pkgver-rpkgrel can be ambiguous to parse in certain cases
11:48 <Shiz> should use a different delimiter maybe
11:48 <Shiz> as yes, - is already usedi n package names
11:48 <Shiz> maybe : :p
11:49 rdutra joined
11:49 <jirutka> fabled: in what cases? it’s very well defined, pkgver cannot contain dash and -r\d is always the last
11:52 <fabled> currently it's not enforced in the strictest sense
11:52 <fabled> and e.g. linux-kernel-2.6
11:53 <fabled> is the last part a version number, or part of the pkgname?
11:53 <fabled> also linux-kernle-2.6-2.6.32-r1 looks slightly confusing
11:54 <fabled> it's certainly something we can live with, and probably something a simple heuristic can figure out
11:54 gromero joined
11:54 <fabled> i would just prefer that the character separating pkgname<->pkgver was not valid in pkgname so there would be no possibility for ambiguity
11:56 <Shiz> if nothing else, : is invalid afaik, because subpackage stuff
11:57 czart joined
12:07 blueness joined
12:10 <jirutka> ncopa: details about LibreSSL + nginx bug https://trac.nginx.org/nginx/ticket/1257#comment:3
12:10 <jirutka> Shiz: nginx responded… https://trac.nginx.org/nginx/ticket/1257#comment:4 (WTF)
12:10 <Shiz> yeah, saw it just now
12:10 <Shiz> lol
12:11 <jirutka> really, WTF such arrogance?!
12:12 <Shiz> don't attribute to malice what can be just an oversight
12:12 <Shiz> i presume the nginx devs have too little hours in a day to fully read everything
12:13 <jirutka> we’re talking about very critical security error here…
12:14 <jirutka> but still, the main problem is in LibreSSL… it supposed to be more secure and reliable than OpenSSL, right? doesn’t look so now…
12:14 <Shiz> libressl is not the issue
12:14 <Shiz> it had a bug before that was fixed now
12:14 <jirutka> it is, they changed the existing behaviour
12:14 <Shiz> apps not understanding the openssl api is a different issue
12:15 <jirutka> yes, but this fix leads to serious regression in third-party apps, so it’s very unresponsible
12:15 <jirutka> and OpenSSL API is horrible piece of shit, so you can’t blame devs to not understand it
12:16 <Shiz> i found this one to be pretty clear though :P
12:16 <Shiz> btw, running a musl build with the new stuff
12:17 <Shiz> s/musl/rust/
12:17 <Shiz> the CI infra fixes that will make the musl PR mergeable
12:17 <Shiz> (hopefully)
12:31 <ncopa> jirutka and Shiz thanks for following it up
12:31 <jirutka> ncopa: we’re discussing it in #xbps right now
12:32 leitao_ joined
12:44 scadu joined
12:46 <rdutra> TemptorSent: hi
12:47 <rdutra> I am testing the release scripts and adding support for ppc64le. Seems that the main script is aports/scripts/mkimage.sh. In order to generate the ISO, should I run it with --profile standard?
12:48 <ncopa> rdutra yes
12:48 <ncopa> but it will generate an iso which boots with syslinux
12:49 <ncopa> i dont know if it makes sense for ppc64le
12:51 <Shiz> jirutka: sigh
12:51 <Shiz> how can one build infra be this broken
12:52 <ncopa> what happened?
12:52 <Shiz> rust, again
12:52 <Shiz> :P
12:52 <Shiz> no matter what targets you get/if it's a cross-compilation, it ALWAYS uses system cc to link
12:52 <Shiz> even for cross-compile targets...
12:52 <ncopa> i thought it was me who broke our build server -> master ...
12:52 <ncopa> :)
12:52 <Shiz> ah no, not today
12:52 <Shiz> :p
12:55 <leitao> ncopa, yea, syslinux is not supported on ppc64le. We would need grub.
12:55 <leitao> is there any arch that uses grubs currently?
12:56 <clandmeter> we need to use it for our aarch64
12:56 <clandmeter> thunderx platform
12:57 <rdutra> leitao: ncopa: btw, I tried to build with --profile standard in ppc64le and it failed missing "linux-grsec" package. The build of this packages is not enabled in ppc64le, do we need it?
12:59 <clandmeter> rdutra, you are talking about grub?
13:01 <rdutra> clandmeter: ah no, I tried to build with --profile standard but I guess not using grub
13:02 <Shiz> rdutra: there's no grsec for ppc64 afaik
13:02 <Shiz> or maybe there is, but i dont think we use it?
13:03 <clandmeter> there is?
13:05 blueness joined
13:06 <ncopa> i thought grsec was only x86, x86_64 and arm (32bit)
13:06 <clandmeter> rdutra, i still dont understand what you try to build?
13:07 <clandmeter> if its grub, then this doesnt depend on kernel.
13:07 <ncopa> leitao i dont think we have any release image that uses grub atm
13:08 <ncopa> rdutra i think you should use --profile vanilla
13:08 <rdutra> clandmeter: ok, I am trying to adapt the script to generate ppc64le iso (bit lost yet but trying to understand how it works)
13:08 <clandmeter> ah ok
13:09 <ncopa> i think the easiest is to start with minirootfs
13:09 <ncopa> which is very simplistic
13:09 <ncopa> designed for docker image
13:10 <rdutra> ncopa: I see...the minirootfs already have support for ppc64le. Fabiano Rosas added it
13:10 <ncopa> and it works?
13:10 <Shiz> ncopa: this seems to imply as much: https://forums.grsecurity.net/viewtopic.php?f=3&t=4158
13:10 <Shiz> but i may be wrong
13:11 <ncopa> Shiz oh ok
13:11 <ncopa> looks like you are right
13:11 <ncopa> i know for sure that aarch64 is not supportted
13:12 <Shiz> that is right
13:13 <rdutra> ncopa: yes, it works. It generates the minirootfs tar.gz
13:13 <ncopa> thats great
13:14 <ncopa> i'd aim for --profile vanilla as next target
13:16 <rdutra> ok, will try it
13:24 <ncopa> rdutra grub fails to build on ppc64le. you need freetype-dev in makedepends
13:24 <ncopa> looks good otherwise
13:26 <rdutra> ncopa: ok, will add the freetype-dev
13:35 <jirutka> Shiz: which build infra, rust’s?
13:36 <Shiz> yeah.
13:45 <jirutka> why I’m not surprised :(
14:11 <leitao> Quick question, is there a branch for 3.6? If there is a FTBFS on 3.6, where should I fix?
14:14 FooBaer joined
14:15 <FooBaer> Hi there, how do I report a broken package in testing without registering yet another one time use account on a bug tracker?
14:16 <FooBaer> Or do I just have to go through all this account registration stuff yet again?
14:17 Emperor_Earth joined
14:18 fabled joined
14:19 <FooBaer> I don't really want to bother the maintainer by sending a mail directly, but it seems like the most reasonable way to do so?
14:23 NightKhaos joined
14:48 sigjuice_ joined
14:54 blueness joined
15:13 <jirutka> FooBaer: well, you can write it here on IRC…
15:13 <jirutka> FooBaer: maybe maintainer of the pkg is here, if you’re lucky
15:19 <jirutka> ncopa: https://grsecurity.net/passing_the_baton.php
15:20 <jirutka> TL;DR - Open Source Security, Inc. no longer releasing open source software
15:24 NIN101 joined
15:28 <leitao> jirutka, ncopa: Quick question, is there a branch for 3.6? If there is a FTBFS on 3.6, where should I fix?
15:30 <jirutka> leitao: no, v3.6 has not been branched yet
15:30 <jirutka> leitao: v3.6 builders builds from the master branch, so the same as edge
15:30 <leitao> jirutka, makes sense. Thanks!
15:33 <mitchty> oh question on that, for moving packages from testing to community should i just ask in here?
15:33 <ncopa> leitao we branch at the same time as we tag v3.6.0
15:33 <mitchty> second question, for things in testing moving to community, does the builders for community have access to the testing packages?
15:33 <ncopa> mitchty yes, you can ask here
15:34 <mitchty> primary reason i ask is ghc an ghc-bootstrap are a bit unique and have cross compilation for armhf
15:34 <mitchty> and even
15:34 <ncopa> if you mean if you can have dependencies/makedepends in testing, then no
15:34 <ncopa> all dependencies needs to be in community or main
15:35 <ncopa> so it needs bootstrapping?
15:35 <ncopa> ghc needs bootstrap?
15:35 <mitchty> yep
15:35 <mitchty> well for non x86_64 arches
15:35 <ncopa> we have the same issue with go
15:35 <arch3y> if I make a pr on a unmaintained pkg and fix it so it builds, does it stay in unmaintained cuase I didnt move it
15:36 <mitchty> ghc-bootstrap has a cross compiled ghc from a debian install
15:36 <mitchty> that can be used to build x86_64 ghc
15:36 <arch3y> the only reason I didnt move it is I figured someone would to review first
15:36 <mitchty> technically it could probably cross compile as well but i've never tested it
15:37 <ncopa> arch3y: move it and make the modifications in the pr
15:37 <mitchty> i'll see if I can't track fabled down and find out how we'd migrate it
15:37 NIN101 joined
15:37 <ncopa> to community or to other archs?
15:37 <arch3y> ncopa: sure thing I will them out into testing
15:37 <mitchty> its not a huge deal but 8.2 is in rc now so would be nice to migrate it
15:37 <mitchty> community for now
15:38 <mitchty> other arches I don't have much access to test with
15:38 <mitchty> yet, getting an armv8 box someday
15:41 <arch3y> just make sure to get a c2
15:41 <arch3y> when you do
15:41 <arch3y> I can test on armv6 arm7 and aarch64 if needed
15:49 <mitchty> sure, until friday i'll be a bit busy at work with a release, but after then could be pressed into getting it working
15:50 <arch3y> let me know if you need a test on actual arm hardware and Ill be glad to help just ping me
15:50 <mitchty> my ulterior goal is using idris to control gpio stuff, so ghc is just a road bump in most ways :)
15:50 <arch3y> ghc is for haskell right
15:50 <mitchty> yep
15:51 <mitchty> so you could now build say, pandoc, or xmonad
15:51 <arch3y> I geuss you prefer haskell over say python
15:51 tmh1999 joined
15:51 <arch3y> yeah pandoc is nicd for markdown conversions
15:51 <mitchty> dependent types are nice
15:51 <arch3y> xmonad is cool looking but Ive never liked haskell personally
15:51 <arch3y> but again I never liked awesome either cuase of lua lol
15:51 <mitchty> but going through a bunch of type theory course books
15:52 <arch3y> yeah but to each his own
15:52 <mitchty> eh, its just a language
15:52 <mitchty> lens in haskell as an example is one of the more interesting things i've ever used
15:52 <arch3y> main issue with things like awesome was they update and break the lang which breaks your config
15:52 <arch3y> which was offputting
15:52 <mitchty> less chance of that in haskell, its all just functions :)
15:53 <arch3y> yeah Ill stick with i3 personally
15:53 <arch3y> I dont have to mess with stuff as much
15:55 <arch3y> ncopa: thanks I have updated all of my prs and moved them
15:56 <arch3y> to limit on the number of prs I make I will hold off on making more until the number comes down a bit
15:56 <arch3y> dont want to overwhelm you guys
15:58 <mitchty> tbh, i just use OS X for my local laptop and run in fullscreen with tmux
16:01 <ncopa> i run alpine on my macbook :)
16:01 fekepp joined
16:02 <arch3y> nice
16:02 <arch3y> you can use xmonad with osx via xquartz cant you
16:25 <przemoc> hi
16:25 <przemoc> https://grsecurity.net/passing_the_baton.php seems dead from all the traffic ;)
16:29 <^7heo> wow that made no sense.
16:29 <^7heo> s/seems dead from all the traffic ;)/is apparently DDoSed from the ingress/
16:29 <^7heo> here, fixed.
16:30 <^7heo> and people usually pass a torch...
16:30 <^7heo> if it's already a baton, we're too late.
16:30 <^7heo> (actually my translation isn't perfect either - 'from' should be 'due to')
16:34 <skarnet> well in a relay sprint, the thing you pass is a baton, not a torch
16:34 <skarnet> (else you could seriously burn yourself)
16:35 <^7heo> right
16:36 fabled_ joined
16:39 <przemoc> kunkku: in awall (at least in AL 3.5) log's prefix doesn't support spaces, which is a bit inconvenient (and was quite unexpected)
16:55 <przemoc> http://dl-5.alpinelinux.org/ was unresponsive for some time, but seems fine now
17:09 <jirutka> ncopa: Shiz: https://github.com/libressl-portable/portable/issues/307#issuecomment-297469867 LibreSSL acknowledged bug :)
17:14 blueness joined
18:05 poptart joined
18:05 poptart joined
18:07 <ncopa> jirutka, Shiz: nice work!
18:07 <ncopa> very nice
18:09 <jirutka> I wonder if this is candidate for CVE, I’ve never reported serious security issue before, so I’m curious :)
18:15 minimalism joined
18:27 <kunkku> przemoc: I will look at the problem
18:33 consus joined
18:52 fekepp joined
19:30 blueness joined
19:47 t0mmy joined
20:45 <Shiz> jirutka: it looks like one to me
21:54 <consus> Guys
21:54 <consus> Does alpine follow fhs?
21:59 <consus> I suggest slightly fixing this patch http://lists.alpinelinux.org/alpine-aports/4573.html in order to actually create /var/mail -> /var/spool/mail, because /var/mail should replace /var/spool/mail according to FHS.
21:59 <consus> > However, programs and header files must be changed to use /var/mail.
22:00 <consus> From here http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.txt
22:23 <skarnet> FHS is actually a very bad standard and /var/mail is one of the reasons why it's the case
22:24 <skarnet> (not that /var/spool/mail is any better, but the fact that FHS insists on this kind of details without addressing the real problem proves how little thought has gone into it)
22:35 <consus> Excuse me?
22:35 <consus> FHS mainly defines more-or-less unified hier
22:36 <consus> Just like POSIX defines more-or-les unified API
22:37 <consus> So I suggest to make maintainters' life easier and follo FHS here
22:37 <consus> Because I think opensmtpd is not the only program that expects it to exist
22:37 <TemptorSent> FHS defines a bunch of semi-random rules that don't actually make much sense and lead to unneeded complexity in many cases.
22:37 <consus> AFAIR mailx too
22:38 <consus> Well, not following FHS is leading to much complexity right now :)
22:38 <TemptorSent> The problem is storage layout vs FHS often results in mixing high-volume, low importance files with low-volume, high importance file in the same directory structure.
22:39 <TemptorSent> In other words, transactional stuff and semi-static database and cache material shouldn't both be in /var/*
22:39 <TemptorSent> Mail and news really should use /var/spool, which is intended for transactional loads.
22:41 <consus> But /var/mail containts user mailboxes
22:42 <consus> I hardly see mbox as "transactional load"
22:51 <jirutka> consus: does OpenSMTPD provide configuration option to change location of this directory, e.g. in build time?
22:51 <consus> Yes
22:51 <consus> The patch is exactly about this
22:51 <jirutka> patching is not a configuration option…
22:51 <jirutka> or what patch do you mean?
22:51 <consus> Have you read it?
22:52 <consus> I mean a patch to abuild repo
22:52 <jirutka> aha
22:52 <consus> It patches APKBUILD
22:52 <consus> In order to change mbox path
22:52 <^7heo> wtf
22:52 <consus> My point is -- it is better to create one symlink than track all softwre that users this dir
22:53 <skarnet> <consus>But /var/mail containts user mailboxes
22:53 <skarnet> that's the very point... it does
22:53 rdutra joined
22:53 <^7heo> we should do an APKBUILD obfuscation contedt
22:53 <^7heo> contest
22:53 <consus> It does
22:53 <consus> So?
22:53 <skarnet> and it's a very bad idea to put user mailboxes in any other place than users' homedirs
22:53 <skarnet> for several reasons that you can look up
22:53 <consus> Okay
22:54 <jirutka> skarnet: lol, no…
22:54 <^7heo> yeah it is
22:54 <TemptorSent> quotas being the most common.
22:54 <consus> So what about the actual problem? :D
22:54 <jirutka> skarnet: this used to be reasonable like in 1970
22:54 <skarnet> to be perfectly clear, I am not objecting to making a symlink or whatever makes existing, crappy, software happy
22:54 <consus> Let's dump the "let's rewrite everything" thing
22:54 <jirutka> skarnet: nowadays you usually don’t have unix account for every email user
22:54 <skarnet> I'm just saying that blindly following FHS is not a good idea
22:54 <consus> I'm talking about the nasty reality
22:55 <^7heo> jirutka: in 1970, when ONE hard drive was all you could afford?
22:55 <jirutka> skarnet: so it doesn’t make any sense to store mailboxes in home directories, cause these users does not have any unix home directories
22:55 <skarnet> consus: then you should ignore most of what I'm saying, because I'm very much about rewriting everything that's badly designed
22:55 <consus> Where at least mailx and opensmtpd are for now broken is this regard
22:55 <skarnet> and it so happens that FHS is badly designed
22:55 <TemptorSent> The nasty reality is that FHS is very poorly conceived and does not scale well to real workloads.
22:56 <^7heo> jirutka: actully using UNIX users for mail isn't a bad idea
22:56 <TemptorSent> Fix the root cause, not the symptom.
22:56 <jirutka> if OpenSMTPd provide configuration option to change this, and it does, then what exactly is broken here? that it uses different *default* option than we want?
22:56 <skarnet> jirutka: if you don't follow the 1 uid = 1 email user way, then you have no business storing mail under /var/mail anyway.
22:56 <^7heo> it's like using UNIX users fr db access
22:56 <^7heo> for*
22:56 <jirutka> no, there’s nothing broken here
22:56 <consus> And since I fail to see any technical reasons not to create /var/mail -> /var/spool/mail for Alpine in order to stop getting weird bugs I suggest to do so
22:56 <jirutka> I mean with OpenSMTPD and our approach
22:56 <^7heo> that's what postgresql does and it's perfect
22:56 <jirutka> I’m not talking about FHS, that’s broken by design, but that’s to totally diferent discussion
22:57 <consus> It just does not work
22:57 <TemptorSent> /var/spool/mail is not the same thing as the user mailbox.
22:57 <TemptorSent> So you may break other things, like actual mail spooling.
22:57 <^7heo> TemptorSent: I think the point was about /var/mail
22:57 <consus> How?
22:57 <skarnet> mail spooling in /var/spool is so 1990
22:58 <jirutka> ^7heo: mapping unix users to DB users is only on of many options in Pg, it makes sense e.g. for user postgres, it does not for almost all other use cases
22:58 <consus> /var/spool/mail is used for both now
22:58 <TemptorSent> consus Because the mail spool and the user inboxes may conflict.
22:58 <consus> I cannot remember any bugs related to this
22:58 <consus> Can you provide some additional info?
22:58 <TemptorSent> Yeah, that's bad form.
22:58 <skarnet> well, with a /var/mail symlink to /var/spool/mail, it would *still* be used for both
22:58 <consus> I mean it works fine everywhere
22:59 <jirutka> that’s not a valid argument imo…
22:59 <consus> In OpenBSD, in Gentoo, in CentOS
22:59 <TemptorSent> Sure, as long as you don't run out of space.
22:59 <^7heo> jirutka: for mail too
22:59 <consus> Well
22:59 <TemptorSent> The problem is if a user mailbox grows too large, ALL incoming mail fails.
22:59 <consus> The fix does exactly te same thing
22:59 <TemptorSent> Real world problems here, not toybox size.
22:59 <consus> I mean the proposed by the maintainer
23:00 <consus> *the one
23:00 <jirutka> if /var/spool/mail and /var/mail are semantically different, as TemptorSent says, if I understand that correctly, and if this still applies at 21st century, then symlinking them doesn’t look like a good solution imo…
23:00 <consus> Errr
23:00 <consus> Hear me out please
23:00 <skarnet> how about doing things right and putting mail for /etc/passwd users into their homedir, and for non-/etc/passwd users, properly configuring the MDA so it has sane defaults?
23:00 <jirutka> b/c that would change it for all, not just OpenSMTPD
23:00 <consus> The ix in APKBUILD does the *VERY SAME THING*
23:00 <consus> But with compile-time option
23:00 <jirutka> no, thhat’s different
23:00 <consus> No it's not
23:01 <TemptorSent> If you want to have things fail sanely, you want /var/spool/mail on a different partition/dataset than /var/mail or $HOME/mail
23:01 <consus> The opensmtpd will deliver the mail there
23:01 <jirutka> hey, this is not OpenBSD
23:01 <jirutka> OpenSMTPD does not have exclusive rights for /var/mail or /var/spool/mail, does it?
23:01 <consus> No it does not
23:01 <jirutka> how can we know if some other software use one of these as well…?
23:01 <TemptorSent> You can get away with doing it wrong, but expect things to REALLY break when something gets fubared, not just fail to deliver to the impacted user.
23:02 <consus> ERr
23:02 <consus> Because it does!
23:02 <jirutka> telling OpenSMTPD to use /var/spool/mail instead of /var/mail is local setting for single app, making symlink aaffects global space
23:02 <consus> Say mailx uses /var/mail
23:02 <^7heo> ok too much spam here for this hour of the day
23:02 <^7heo> have fun trolling everyone
23:02 <skarnet> ^7heo: you're one to talk
23:03 <^7heo> skarnet: nah actually
23:03 <jirutka> consus: please continue
23:03 <skarnet> for once there's a mildly interesting discussion on what the right thing is
23:03 <TemptorSent> The point is simply that the mail spool should be used for the transactional load, and the users mailboxes should not be in the same place on a production box.
23:03 <^7heo> skarnet: maybe it's my screen being to small
23:03 <^7heo> skarnet: but I can't follow shit
23:03 <skarnet> your screen? is that how you call it?
23:04 <* skarnet> is already out
23:04 <TemptorSent> *LOL*
23:04 <^7heo> skarnet: that's too far fetched for being funny
23:04 <^7heo> skarnet: plus, I am actually annoyed at my phone
23:05 <skarnet> phone? ok, it IS your screen being too small
23:05 <^7heo> it sucks a LOT. I guess I cnt easily be amused anyway
23:06 <^7heo> anyway, I am being offtopic; please continue your discussion on FHS and how to do mail in the least bad way
23:06 <^7heo> o/
23:06 <skarnet> ANYWAY. If there really is a problem with opensmtpd or whatever else in their default config, the right thing is to check the config and make sure they have sane defaults.
23:06 <awilfox> /var/spool/mail is for mail queues; /var/mail is for mailboxes
23:06 <skarnet> And sane defaults means not FHS.
23:07 <awilfox> this is the way it has always been done, and I can go any way you want for this: nixos, fhs, sendmail, opensmtpd, postfix, qmail
23:07 <TemptorSent> awilfox : Correct -- you're expected to clean out the spool when you check your mail. It's essentially 'Incoming'.
23:07 <skarnet> awilfox: yes. (If you're using a badly designed MTA.)
23:08 <awilfox> TemptorSent: no, OUTGOING queues
23:08 <skarnet> TemptorSent: no.
23:08 <skarnet> awilfox: stop typing faster than me!
23:08 <^7heo> huhu
23:08 <awilfox> TemptorSent: what the fuck is an incoming queue, that isn't how this works; mail is stored in either ~/.maildir or /var/mail/$USER
23:08 <skarnet> or ~/Mailbox
23:08 <TemptorSent> /var/spool/mail/$USER = incoming mail queue.
23:08 <^7heo> or ~/Mail
23:09 <jirutka> Gentoo and CentOS symlinks /var/mail to /var/spool/mail
23:09 <awilfox> TemptorSent: why is an MDA queuing incoming mail? unless maildir is full, in which case it should be either refusing to deliver (Sorry, that mailbox is full) or screaming at the postmaster
23:09 <skarnet> jirutka: yeah, so Gentoo and CentOS are doing something idiotic, what else is news?
23:10 <awilfox> jirutka: I don't care what broken distros do. this about doing the Right Thing, what users and MTAs/MDAs expect, not being compatible with brain damage
23:10 <TemptorSent> awilfox: It's pretty common when something such as POP3 is in use.
23:10 <jirutka> I’m not sure if it’s really idiotic…
23:10 <skarnet> pop3 should read from user mailboxes
23:10 <awilfox> TemptorSent: no, I have run pop3 servers, the pop3d reads from maildir.
23:10 <consus> awilfox: So it's you who will track down every program in tree and test that it does not use /var/mail, right?
23:11 <skarnet> consus: we're not very much for passive-aggressiveness around here
23:11 <TemptorSent> awilfox: I'm referring to having the mailbox full and needing to queue files.
23:11 <awilfox> consus: I don't know if that would be accepted even if I did it
23:11 <consus> skarnet: So don't be one :)
23:12 <skarnet> I'm sorry?
23:12 <consus> We just discussed it with jirutka
23:12 <TemptorSent> awilfox: Although such configs are much less common these days because most everyone is always-on.
23:12 <consus> E.g. the mail program searches /var/mail for it's mail
23:12 <consus> So
23:12 <consus> If the patch in question will be accepted then opensmtpd cannot be used with mail
23:12 <awilfox> this is just making me feel like I need to /disconnect freenode quicker tbh; forget I even contributed my opinion
23:12 <consus> So we have to patch mail too
23:12 <awilfox> you will break what you will
23:12 <awilfox> have ~lots~ of fun
23:13 <skarnet> awilfox: please don't leave me
23:13 <skarnet> I need you
23:13 <jirutka> it’s just damn directory location, what matters the most here what most of the programs expect
23:13 <TemptorSent> /var/spool/mqueue is outgoing, at least for sendmail.
23:13 <consus> jirutka: Finally, the voice of reason
23:14 <skarnet> jirutka: the job of a *distribution* is to *configure* programs, to implement a *distribution policy*
23:14 <skarnet> preferably a sane policy
23:14 <jirutka> skarnet: yes, of course
23:14 <skarnet> so how about doing that
23:14 <skarnet> instead of catering to brain damage
23:14 <consus> skarnet: You have the tree publicly available. We want patches, and we want them now.
23:14 <jirutka> skarnet: but for what reasons do you configure /var/spool/mail as right policy and /var/mail as bad policy?
23:15 <^7heo> gosh so much tension in here
23:15 <skarnet> jirutka: I don't find either is good policy
23:15 <jirutka> skarnet: yeah, see?
23:15 <^7heo> consus: who are you exactly to demand patches? let alone now... it's the first time I see you here.
23:16 MH0815 joined
23:16 <consus> ^7heo: no it's not
23:16 <^7heo> yeeeess it is
23:16 <consus> ^7heo: No
23:16 <skarnet> that's why I don't care about symlinks and I'm saying FHS is bad: correct policy for MTAs and MDAs does not involve either
23:16 <consus> ^7heo: And I have proofs, my friend
23:16 <^7heo> you can't tell me what I see for the first time
23:16 <consus> ^7heo: Oh I can
23:16 <^7heo> I'm everything but your friend
23:16 <^7heo> trust me
23:16 <consus> ^7heo: You are now
23:16 <^7heo> I know who you are
23:16 <TemptorSent> Ideally, mail actually delivered to users (as opposed to left for them to pick up) should go directly to their home directories.
23:17 <skarnet> TemptorSent: that's right.
23:17 <skarnet> Or to a MDA-configured database, for non-/etc/passwd users.
23:17 <jirutka> skarnet: we both know that FHS is broken by design, but we still use it in Alpine, deal with that; if you see both options as bad, then it’s about choosing less evil for now, until we finally reject FHS and redesign complete system
23:17 <skarnet> and that INCLUDES mail "left for them to pick up"
23:18 <jirutka> skarnet: I see as less evil to use the location which most programs expect
23:18 <TemptorSent> Mail that is sitting in /var/spool/mail is basically sitting in the po box, waiting for the owner to come pick it up, but it can't be delivered directly.
23:18 <skarnet> jirutka: delivering mail to homedirs isn't exactly revolutionary or FHS-breaking
23:18 <skarnet> /var/mail and /var/spool/mail can remain in the base layout for all I care
23:18 <TemptorSent> skarnet: /var/spool/mail is appropriate for virtual users and such where there is no unix home directory.
23:19 <jirutka> skarnet: we use /run instead of /var/run and still keep /var/run symlink to /run; isn’t this quite the same?
23:19 <skarnet> not at all
23:20 <skarnet> TemptorSent: I, too, have run pop3d and imapd servers, and like awilfox, I can assure you that those servers will look inside user's mailboxes, not inside whatever "pobox" you're thinking of.
23:21 <skarnet> jirutka: /run makes sense, this is one of the few creations from main distros that actually make sense - because you need a rw tmpfs before mounting filesystems
23:22 <TemptorSent> skarnet: What did you do when you didn't have real users and you were using vpop?
23:22 <TemptorSent> skarnet: Say 12,000 or so mail-only users with no unix accounts.
23:22 <awilfox> "You have the tree publicly available. We want patches, and we want them now."
23:22 <skarnet> and its function basically duplicates the function of /var/run, except you need it before /var, so creating /run as a tmpfs and making /var/run a symlink to it for compatibility makes perfect sense.
23:22 <awilfox> consus: do you have a commit bit on the tree
23:22 <awilfox> consus: can you directly commit to alpine
23:22 <consus> awilfox: No, I can't
23:23 <consus> awilfox: Why?
23:23 <awilfox> okay, so the "we" you speak of is the community
23:23 <skarnet> TemptorSent: it's exactly what I have right now, and I configured the MDA to use its own place.
23:23 <awilfox> consus: because that behaviour would be enough for me to /part #alpine-* and stop recommending the distro to anyone, if you were an actual developer for it and actually were speaking for the project itself
23:23 <consus> I speak for people who have broken software because some dude wants ponies and rainbows :)
23:24 <skarnet> TemptorSent: I use vpopmail, and created a /home/vpopmail place to store the user mailboxes (actually maildirs)
23:24 <TemptorSent> skarnet: Yeah, it's obviously saner to use a locally configured directory.
23:24 <consus> And I really want to remove that /var/mail -> /var/spool/mail from my ansible configuration. Because that's what package managers are for :D
23:24 <jirutka> awilfox: wtf? why are you escalating this…?
23:25 <jirutka> awilfox: we’re just discussing it
23:25 <awilfox> jirutka: I was not the one making unreasonable demands from the community
23:25 <consus> awilfox: You take it too serious
23:25 <awilfox> and I will not apologise for calling out abusive behaviour in projects
23:26 <awilfox> that is how you end up with gentoo
23:26 <TemptorSent> skarnet: Got it - I used to run several medium-to-large mail servers, and we broke things out using ldap on a number of linked servers, so /var/spool/mail ended up being the best bet.
23:26 <arch3y> not every version of linux is everyones cup of tee
23:26 <consus> No, Gentoo is a very different beast. They so obsessed with politeness and rules they stuck with the enormous lack of manpower.
23:26 <awilfox> as skarnet said, I have a directory (mine is /srv/vpopmail for virtual users, but that's just down to my own preference)
23:26 <arch3y> everyone has an opinin the devs will build it how they see fit
23:27 <awilfox> the correct default behaviour would be to use /var/mail and allow users to change it
23:27 <skarnet> TemptorSent: lolldap - no wonder you had trouble :D
23:27 <awilfox> cite: 17 years of maintaining email servers
23:28 <^7heo> consus: no awilfox does not take it oo serious
23:28 <skarnet> awilfox: no, the correct default behaviour would be to choose a distro policy, stick to it by configuring all the MDAs' APKBUILDs, and document it
23:28 <skarnet> and /var/mail is a bad technical choice
23:28 <^7heo> consus: we're many finding your behavior despicable
23:28 <^7heo> too serious*
23:28 <jirutka> awilfox: do you know when I sent the last patch to Gentoo? when some reviewer wanted from me to use some specific style of commit message that I haven’t found in last 100 commits in the aports and when I pointed this, he senselessly assumed that I’m arguing with commit style in my fork, not official aports, that would obvious don’t make any sense, so I’ve responsed that I’m not an idiot to do that… and he sent me email with serious
23:28 <jirutka> warning about violating Code of Conduct
23:29 <consus> Oh my god
23:29 <consus> Yes
23:29 <consus> I was threated with a goddamn lawsuite
23:29 <consus> In Gentoo
23:29 <skarnet> awilfox: you know as much as I do that most users will not change the default, and that's why distros must provide good defaults
23:30 <awilfox> skarnet: what is your rationale for /var/mail being a bad technical choice?
23:30 <consus> That was fun
23:30 <jirutka> awilfox: I didn’t call him idiot, I just asked him to not treat me as an idiot or something in this sense… so please, don’t take it so seriously ;)
23:30 <awilfox> that is the standard, and beyond just being the standard, it is where it makes the most sense imo
23:31 <skarnet> enforcing that root delivers the mail (for writing rights in /var/mail) instead of the mda running as the user; enforcing mbox format; making quotas more difficult to compute
23:31 <skarnet> as a qmail user, you should know all this :)
23:31 <consus> > for writing rights in /var/mail
23:31 <consus> Whaat?
23:31 <awilfox> skarnet: why would root need to deliver the mail? that is why qmail runs as its own uid.
23:31 <consus> OpenSMTPD uses privsep for that
23:31 <consus> postfix uses privsetp for that afair
23:32 <jirutka> consus: heh, funny, I’ve heard quite recently that Gentoo has serious problem with not enough contributors… maybe that’s why
23:32 <consus> jirutka: Yep
23:32 <consus> jirutka: They're too elite for the regular people
23:32 <skarnet> if you want to be able to create a mailbox in /var/mail, you need to be root
23:32 <consus> jirutka: I got banned on irc for cursing while DEBUGGING THEIR PACKAGE BUGS
23:33 <skarnet> qmail-local runs as the user it's delivering to, because it only has to write to the user's homedir, which is guaranteed writable for the user
23:33 <consus> skarnet: drwxrwsr-t 2 root mail 120 Jan 9 2016 /var/spool/mail
23:33 <awilfox> jirutka: consus: I am ex-gentoo. was run out by the leadership telling me to "stop being so controversial". the controversy I started? filing a coc complaint after some other dev followed me to personal blog and made bunch of slurs because I am not in perfectly standard sexuality
23:33 <consus> skarnet: Yeah
23:33 <consus> skarnet: Right
23:33 <consus> skarnet: Ever heard of groups? :D
23:35 <awilfox> drwxrwx--- 11 qmail qmail 4096 May 25 2014 /var/mail
23:35 <skarnet> of course you can do that, but that doesn't help with the same problem
23:35 <skarnet> namely, if an attacker takes control of the MDA, they can read every user's mailbox
23:35 <awilfox> if they are virtual users, it can't be owned by any other user.
23:35 <awilfox> I thought that was the whole point of this discussion
23:35 <awilfox> virtual users
23:36 <awilfox> if they have real logins on the box, deliver to ~/.maildir and get off my lawn
23:36 <skarnet> awilfox: it's exactly what I've been saying from the start
23:36 <awilfox> but those two configurations are very difference
23:36 <skarnet> deliver to the homedir
23:36 <awilfox> different*
23:36 <consus> If an attacker gains user uid it can do pretty much everything. So delivering to $HOME is no less dangerous.
23:36 <skarnet> consus: you misunderstand me.
23:37 <consus> Perhaps. Could you clarify your point?
23:37 <skarnet> with the MDA running as a user, if an attacker gains control of it, it can read that user's mail.
23:37 <consus> Yes
23:37 <skarnet> with the MDA running as group mail and every mail in /var/mail, if an attacker gains control of it, it can read EVERYONE's mail.
23:37 <consus> That's not quite true
23:38 <consus> $ ls -l /var/spool/mail
23:38 <consus> total 0
23:38 <consus> -rw------- 1 consus mail 0 Jan 9 2016 consus
23:38 <awilfox> skarnet: so then there is important thing to discuss here: if you are ISP, let us say you serve San Francisco - area has 1.3m people. you will probably have more than 65535 users of your ISP (if you are good). what do you do for email? you can't give them all uids on the mail box, unless maybe you have a bunch of mail boxes...
23:38 <skarnet> and how does that mailbox get appended
23:38 <consus> very simple -- opensmtpd spawns a process with uid = user-users-uid
23:39 <consus> *your-user-uid
23:39 <awilfox> so you use virtual users, i.e. logins are in a db, and mail is delivered to: ....?
23:39 <skarnet> awilfox: of course you need virtual users, that's not the point
23:39 <awilfox> skarnet: where is mail delivered to virtual users? who owns those boxes?
23:39 <consus> And *YOU* can create a mbox in /var/spool/mail without bein root too
23:39 <skarnet> awilfox: who cares? it's MDA-specific policy.
23:39 <consus> Because you're in the mail group
23:40 <consus> That's what I'm talking about
23:40 <consus> So everything goes in your uid space
23:40 <skarnet> consus: the MDA runs as uid user and group mail?
23:41 <consus> The MDA runs as root
23:41 <consus> Ah
23:41 <consus> No
23:41 <consus> MDA runs uid user
23:41 <consus> Sorry
23:41 <awilfox> skarnet: I think the point is that most people running alpine are not running sdf.org-style servers where people have uids, they are running webby bullshit like docker and ruby and are going to more than likely have virtual users. so alpine should default to that config (but hopefully the agent makes it easy to reconfigure to ~ for the good case)
23:41 <consus> and group mail
23:42 <consus> The daemon runs as root, the MTA runs as smtpd user, the queue handler runs as smtpq user
23:42 <skarnet> awilfox: I totally understand what you're saying, and I'm not advocating a lack of virtual users, at all. I'm just saying /var/mail may not be the best place to store mail dbs for virtual users. But then again, it's a suitable place too, and I really don't care.
23:43 <consus> The MDA runs as your-user-uid
23:44 <skarnet> consus: ok, I don't see any obvious problems with that setup. Still, it's way more complicated than it needs to - if the MDA just delivers in a user's homedir, it doesn't need specific group rights, you don't need a sticky bit, etc. etc. And I don't like things that are more complicated than they need to be - chances are there are evil corner cases we don't see.
23:45 <consus> skarnet: You can drop the sticky bit
23:46 <consus> skarnet: It's Gentoo thing that does not have to be there for the whole thing to work
23:46 <skarnet> no you can't: you don't want an attacker to delete other people's mailboxes
23:46 <consus> Err
23:46 <consus> Yes, you do not want
23:46 <consus> So let them be consus:consus instead of consus:mail
23:47 <consus> Since MDA delivers as your UID it doesn't care for the group
23:47 <skarnet> and now you can't create mailboxes
23:47 <consus> Why?
23:47 <consus> /var/lib/mail
23:47 <consus> 0770
23:47 <consus> No sticky bit
23:47 <consus> Your user in group mail
23:47 <consus> Can't see what's wrong with that
23:48 <skarnet> what are the rights for /var/mail
23:48 <consus> 0770
23:48 <skarnet> uid:gid
23:48 <consus> Say root:mail
23:49 <skarnet> if the MDA has group mail rights, it can delete other people's mailboxes
23:49 <skarnet> if it doesn't, it can't create mailboxes
23:50 <skarnet> (unless it's running as root)
23:50 <consus> Err
23:50 <consus> Okay
23:50 <consus> Let's try it out
23:51 <consus> Well yeah
23:51 <consus> It can
23:51 <consus> I see your point
23:53 <TemptorSent> Even sticky is a problem, because you can create a mailbox that collides with a username that has no mail currently, and either receive their mail (if the MDA doesn't check) or DOS them.
23:54 <skarnet> that's the corner case I was talking about
23:54 <consus> You cannot create a mailbox or another user
23:54 <TemptorSent> Yeah, and it's an ugly one that has been used for real exploits.
23:54 <consus> *for
23:54 <consus> If MDA is running with uid of that user
23:54 <TemptorSent> touch /var/mail/foo
23:54 <TemptorSent> Done.
23:55 <consus> Err
23:55 <consus> Permission denied
23:55 <consus> :D
23:55 <skarnet> not if you have group mail rights
23:55 <TemptorSent> GID.
23:55 <consus> Also you forgot about the ownership
23:55 <skarnet> a compromised MDA can DoS other people
23:56 <TemptorSent> Or worse, allow a leak.
23:56 <skarnet> iow, /var/mail is shit, which I've been saying for an hour now
23:56 <skarnet> so I'll now retire for the night.
23:57 <TemptorSent> It's only appropriate for virtual users IMHO, where the perms have nothing to do with the user.
23:57 <consus> If mda is running with pwuid:pwgid it cannot write to another users file
23:57 <TemptorSent> And that should probably be in a locally configured place.
23:58 <TemptorSent> Sure it can, all you have to do is set the perms to 666
23:58 <consus> Right
23:58 <consus> Good point :D
23:58 <TemptorSent> Anyway, I'm off for dinner..
23:58 <TemptorSent> There are a lot of ugly corner cases to consider.
23:59 <consus> Off to sleep
23:59 <consus> Or at least for something that is left of it