<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  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 _2_7  
28 29 30 31
00:03 <arch3y_> does the linux-headers pkg provide the kernel headers for the linux-hardened kernel
00:07 BitL0G1c joined
00:20 saintdev joined
00:21 rejadatodo joined
00:40 <jirutka> andypost: are you still here?
00:41 <andypost> jirutka, yep, digging why php7-soap does not work
00:42 <xentec> arch3y_, linux-*-dev pkgs do
00:44 <arch3y_> xentec: thats what I thought thanks
00:44 <jirutka> andypost: I’d like to ask you, could you please create php7-* pkgs for extensions we used to provide php5-* package for in v3.5 main or community? there are few missing and I’m afraid that users may complain that they disappeared in v3.6
00:46 <andypost> jirutka, do you mean base packages or the list from https://goo.gl/w2qgEz
00:46 <jirutka> andypost: from the list, only pkgs in main or community and ofc the ones that support php7 and are not already dead
00:48 <jirutka> andypost: I’ve moved all php7-* from testing that were in main or community as php5-* plus php7-redis and some other i don’t remember now
00:49 <jirutka> andypost: but I didn’t find php7-* pkg for some
00:53 <jirutka> andypost: hm, actually, they are probably in vakartel’s PR https://github.com/alpinelinux/aports/pull/1061, but in not very good shape and also I doubt that he actually tested them, b/c he added check function, but apparently don’t bother that for most packages no test is actually run b/c of missing extensions and for the rest some tests fail, but the failures are just ignored
00:57 <andypost> jirutka, as I see only php7-apcu & php-xdebug are affected by php7 version change, the rest are php5
00:57 <andypost> jirutka, and both works, just installed and tested
00:57 <jirutka> andypost: like php5-only?
00:58 <andypost> jirutka, yes, the rest are php5 only
00:59 <andypost> jirutka, php7-redis broken
01:01 <andypost> jirutka, https://gist.github.com/andypost/6b34d8db1f94197d6c04ae41b707ab77
01:03 <andypost> jirutka, do you have any idea how to make check() for php? installing each extension and use php --re apcu for example
01:04 <jirutka> andypost: this is normal for php extensions, they depend on symbols from php executable, so ldd always reports many not found symbols
01:06 <jirutka> andypost: or do you see some extensions needed to be added to deps…? I don’t remember what symbols are exported by php executable
01:08 <jirutka> andypost: about check(), I was trying to find some way how to tell that stupid php test script to load specific extensions in addition, but found nothing; probably the only usable env. variable is some that referes php.ini file that should be loaded, we can probably generated file just with load_module (or how is that called), but I haven’t tried it yet
01:09 <jirutka> andypost: the hack I used in php7 pkg to affect load order for tests cannot be used for extensions as-is
01:17 <andypost> jirutka, I was wrong about php-soap - it works but php-xdebug needs rebuild https://gist.github.com/andypost/6b34d8db1f94197d6c04ae41b707ab77
01:19 BitL0G1c joined
01:20 <jirutka> andypost: yeah, someone reported it on bugs.a.o, that xdebug is broken, but I don’t know why
01:21 <jirutka> andypost: so it really needs to be rebuilt?
01:22 <andypost> jirutka, yep, but I guess better to to increase "pkgrel" to 1
01:23 <jirutka> not better, but necessary, to rebuild it :)
01:25 <jirutka> andypost: okay, I’ve pushed rebuild
01:26 <jirutka> andypost: and few changes for php7 pkg https://github.com/alpinelinux/aports/pull/1345 … I’ll add pear/pecl split later
01:26 <jirutka> andypost: into this PR
01:26 <jirutka> andypost: that’s why WIP
01:27 <andypost> jirutka, https://github.com/alpinelinux/aports/pull/1346
01:28 <jirutka> andypost: php 7.0 is gone…
01:29 <jirutka> andypost: there’s only community/php7 in version 7.1.4
01:29 <jirutka> andypost: and I’ve already pushed https://github.com/alpinelinux/aports/commit/26d96b3a7913462c8c094dd36f662892f540d5cb
01:30 <jirutka> andypost: I need to go sleep now, too tired; see ya! o/
01:31 <andypost> jirutka, ah are fast)
01:37 LouisA joined
01:39 BitL0G1c joined
01:42 blueness joined
01:48 leitao joined
01:56 s33se_ joined
02:01 blueness joined
02:49 tkharju joined
03:03 Long_yanG joined
03:05 xfix_ joined
03:06 rfs613_ joined
03:07 poptart_ joined
03:18 minimalism joined
03:18 xsteadfastx joined
03:18 scadu joined
03:20 skarnet joined
04:58 <fabled> jirutka, in things like apk the nano-optimizations mean a lot since bulk of the work is repeating the nano-jobs :) ... but it's true some of it could be improved.
05:03 fabled joined
05:11 czart__ joined
05:25 <TemptorSent> fabled: Which specific optimizations are you referring to there?
05:34 blueness joined
06:00 <kaniini> likely things like using apk_istream_splice()
06:01 <kaniini> honestly, apk is pretty decently clean if you sit down and start digging into it
06:04 blueness joined
06:05 <TemptorSent> I'm sure, but the lack of design documentation , obtuse variable names, and minimal comments makes it very hard to follow even for an experienced C coder.
06:06 <TemptorSent> I don't have anything like a clear mental picture of the basic code paths, let alone obscure details.
06:06 vakartel joined
06:09 <TemptorSent> kaniini: It also seems incredibly difficult to reuse various code sections in manners different than their original design (Such as pkgname vs. pkg atom vs. filename parsing)
06:09 <kaniini> as previously stated, atoms are obsolete and not actually used anymore :P
06:10 <TemptorSent> Right now I'm working on stubbing together a bottom-up deptree builder in awk which may be of interest for apk at some point in C.
06:10 <TemptorSent> Okay - can you clarify the term 'atom' vs '$pkgname-$pkgver'
06:11 <kaniini> that's one and the same, it's for display only
06:11 <kaniini> apk itself cares about dependencies
06:12 <kaniini> $pkgname-$pkgver is not a dependency, $pkgname=$pkgver is a dependency
06:12 <kaniini> in reality, we should output $pkgname=$pkgver as the way of describing package 'atoms'
06:13 <TemptorSent> $pkgname=$pkgver is a dependency on the specific atom (meaning atomically defined unit) $pkgname-$pkgver
06:13 <kaniini> the downside to that would be that somebody copy and paste it from apk search and then gets very confused when they dist-upgrade
06:14 <kaniini> you can also do
06:14 <TemptorSent> $pkgname>$pkgver is a dependency on the SET of atoms ($pkgname-$pkgver, $pkgname-$latestpkgver]
06:14 <kaniini> $pkgname><$base64_short_checksum
06:14 <kaniini> to designate a package with a specific checksum
06:15 <kaniini> i guess that probably would have been useful to mention earlier
06:15 <* kaniini> whistles
06:15 <TemptorSent> Set theory says you need atoms for proper dep resolution.
06:15 <kaniini> nope, those are providers
06:15 <TemptorSent> Technically, the atoms should include arch IMHO.
06:16 <TemptorSent> The provider has to resolve to an apk at some point, right?
06:16 <kaniini> anyway i've tried to explain this a dozen times now, so i see no point in explaining it a 13th time
06:16 <TemptorSent> At that point in time, you have to choose a particular atom, since you can't have part of one version and part of another (hence tha atomic part)
06:16 <kaniini> not necessarily
06:17 <TemptorSent> What I'm looking for is what maps a successful dep resolution to the apk you need to fetch to actually install it?
06:17 <kaniini> if i told you, i'd have to kill you
06:17 <TemptorSent> *lol* Yeah, that's what I was afraid of.
06:18 <TemptorSent> That mapping is where things go to hell logically between deps and 'atoms'
06:18 <kaniini> again: atoms don't exist. they are like an appendix.
06:19 <kaniini> don't even think about them when trying to understand how apk works, it's a waste of time
06:19 <TemptorSent> Well, they exist for the purpose of naming an apk, which is where I'm having real problems with the way apk works.
06:19 <kaniini> oh
06:19 <kaniini> apk itself
06:19 <kaniini> does not care what the apks are named, actually
06:20 <kaniini> the APKINDEX tells it that
06:20 <kaniini> :)
06:20 <kaniini> it just /happens/ that abuild produces apks like foo-1.0-r2.apk
06:20 <TemptorSent> Okay, so how the hell am I supposed to know the FILENAME of the apk I end up fetching BEFORE I fetch it?
06:20 <kaniini> and that for historical reasons, apk-tools renders the formats that way
06:20 <kaniini> like i said
06:20 <kaniini> it's in the APKINDEX
06:21 <TemptorSent> Which I can't actually query.
06:21 <kaniini> sure you can
06:21 <kaniini> hint: it's a text file
06:21 <TemptorSent> That's nice, but I don't know what the dep-solver is going to end up with until I run it.
06:21 <TemptorSent> And I have no reverse-index.
06:23 <TemptorSent> So I do 'apk fetch linux-hardened zfs-hardened zfs' -- what files do I actually get? How about with a recursive fetch? Virtuals? That's where it goes to hell real fast for scripting anything.
06:24 <kaniini> so for example,
06:24 <kaniini> you have
06:24 <kaniini> P:p11-kit
06:24 <kaniini> C:Q1xRdw3TK+N+0zc5r9/3U3hwvvI64=
06:24 <TemptorSent> Currently, to handle a recursive fetch, I get to create a new directory and fetch -r -o to there, then read the list of files I actually got
06:24 <kaniini> V:0.23.2-r1
06:24 <kaniini> and you can do
06:25 <kaniini> raccoon:~# apk add 'p11-kit><Q1xRdw3TK+N+0zc5r9/3U3hwvvI64='
06:25 <kaniini> (1/2) Installing libtasn1 (4.10-r0)
06:25 <kaniini> (2/2) Installing p11-kit (0.23.2-r1)
06:25 <TemptorSent> Since doing simulate first isn't gurarenteed to give me back the same list I actually get when I fetch (say update was run from somethign else between the ccalls)
06:26 <kaniini> apk does not even care about the -rXYZ part
06:26 <TemptorSent> Yeah, apk add works great -- its FETCH that screws me.
06:27 <TemptorSent> Add acts atomically, but since I can't generate actual atoms and fetch those, fetch does not.
06:28 <TemptorSent> I also apparently can't just hand it an apk file either :)
06:29 <TemptorSent> So if fetch could fetch by actual filename, that would solve it.
06:29 <TemptorSent> But otherwise, it's a guessing game.
06:30 <TemptorSent> So the checksums is now the actual atom for set-theoretic purposes?
06:31 <TemptorSent> Or UUID if you will?
06:33 <kaniini> well
06:33 <kaniini> its a checksum
06:33 <kaniini> lol
06:34 <TemptorSent> Yes, I mean for purposes of meeting the set-theoretic requirements of uniqueness, onto, and one-to-one.
06:34 <kaniini> it is most likely unique, sure
06:34 <TemptorSent> It doesn't work well in terms of being well-ordered however.
06:35 <TemptorSent> In that respect, the former atoms are superior.
06:36 <kaniini> well, they still exist technically. it's just that the depsolver doesn't look at it like that
06:36 <TemptorSent> Ideally, a single string could both uniquely identify AND properly order the elements of the set.
06:37 <TemptorSent> So any new version of a package sorts logically.
06:39 <TemptorSent> Even better would be allowing identification down to the individual file level using the same scheme.
06:41 <kaniini> sounds good, look forward to the patch
06:41 <* kaniini> runs away
06:41 <TemptorSent> (tar -xzf $apkfile $@)
06:41 <TemptorSent> I have it in awk :)
06:43 <TemptorSent> The next logical step is to make it a set of proper merkle dags, one for semantic name, one for content, and possibly one for meta-data.
06:44 <TemptorSent> Right now I'm just carrying the checksums for each dep, not yet checksumming levels in the dep tree.
06:46 <TemptorSent> If we cascade the checksum for each dep down its entire dep tree, we can significantly cleanup the dep resolution and caching.
06:47 <* kaniini> is not here
06:47 <TemptorSent> This allows cool things like delta updates.
06:48 <TemptorSent> And REAL CI support.
06:50 <TemptorSent> I believe it would also allow almost complete autodetection of deps for abuild.
06:51 <* kaniini> really is not here.
06:51 <TemptorSent> That's okay, I'm not all here either :P
06:51 <* kaniini> backs out of the channel slowly.
06:52 <* kaniini> decides to do it (whatever it is) with ubuntu instead
06:52 <TemptorSent> *LOL*
06:55 <TemptorSent> Yeah, I've obviously spent too much time designing data structures for my own good :P
07:09 <TemptorSent> kaniini: An example deptree is at http://termbin.com/hgp5
07:10 <TemptorSent> The Manifest is at http://termbin.com/pe7v
07:11 <TemptorSent> And the index is at http://termbin.com/us7n
07:13 <TemptorSent> Sequence is generate manifest/index for each package, concat them, then generate direct deps list for each item in the manifest, resolve them against the index, and generate a dep-tree.
07:13 t0mmy joined
07:15 <TemptorSent> Clear as mud?
07:17 <TemptorSent> Generating the merkle dag of the dep tree is a matter of starting at the root and hashing your way up the tree.
07:19 <TemptorSent> Run the same against both names and hashes and you have semantic deps as well as explicit content deps.
07:28 <mosez> looks like my php containers are still broken. how can i fix the php packages?
07:29 <mosez> getting warnings like PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php7/modules/mysqli.so' - Error relocating /usr/lib/php7/modules/mysqli.so: mysqlnd_poll: symbol not found in Unknown on line 0
07:37 __0xAX joined
08:03 <mosez> ok found my resolution
08:20 stateless joined
08:35 consus joined
08:37 fekepp joined
08:42 blueness joined
09:22 <clandmeter> mosez, nice
09:23 <clandmeter> if you can jirutka know what fixed it. he has been working on php.
09:34 <mosez> clandmeter: reinstalled the php packages and fixed my configs :D
09:49 saintdev joined
09:54 mjeanson joined
09:55 LouisA joined
09:57 blueness joined
10:04 blueness joined
10:05 rejadatodo joined
10:08 YoursTruly joined
10:24 rnalrd joined
10:34 hairyhenderson joined
10:41 jcloud joined
11:14 blueness joined
11:17 <jirutka> clandmeter: mosez: this must be some user-side problem, I’m sure that config loading mysqli has higher prefix than my mysqlnd, b/c i needed to add a workaround for it to abuild and it failed even in tests running in check phase when the order was incorrect
11:18 <jirutka> fabled: I was kidding about nano-optimizations, the point was that cargo index is so brutally inefficient in comparison with apkindex :)
11:33 cyteen joined
11:36 <jirutka> btw it seems that there’s some upstream bug in php 7.1.4 with zip module and maybe some other, http://bugs.alpinelinux.org/issues/7261
11:58 gromero joined
11:58 nmeum joined
12:05 nmeum_ joined
12:32 gromero joined
12:51 nmeum joined
12:59 farosas joined
13:06 nmeum joined
13:12 stateless joined
13:39 <Shiz> jirutka │ Shiz: ^ that’s pretty good question! is not very good entropy better than no entropy and so no encryption…? ;)
13:39 <Shiz> no
13:39 <Shiz> TemptorSent │ Shiz: Any thoughts on a good means of initilizing the entropy pool when we don't have a HWRNG or user activity? (Embedded/VM)
13:40 <Shiz> saving entropy to disk on reboot or using an entropy gathering daemon
13:44 <skarnet> ^
13:44 <skarnet> for VMs, there's a way to link the guest's entropy generation to the host's hwrng, if any
13:54 <jirutka> jirutka: ^ that’s true, there’s virtio-rng or something like that, that’s what I did to solve this problem
13:54 <jirutka> skarnet: but still, you can’t do that on embedded devices if it don’t have HW random generator
13:57 <skarnet> Indeed, but in that case having a bad starting entropy pool is a security issue that's inherent to the device
13:57 <skarnet> lacking a reliable way to get entropy is just as bad, if not worse, as lacking a hw timer
13:58 <Shiz> let me put it like this
13:58 <Shiz> if you start providing entropy that is reproducable by an attacker, your crypto is hosed
13:58 <Shiz> it's better to have no crypto at all than crypto that you believe is secure but is not
13:58 <skarnet> ^
14:06 <jirutka> Shiz: but is that entropy computed by LibreSSL in the code you’ve referenced really reproducible by an attacker…?
14:06 <Shiz> yes
14:06 <jirutka> in real-world, not in lab…?
14:08 <Shiz> maybe the mmap() part and the getauxval(AT_RANDOM) parts aren't
14:08 <Shiz> the rest, yes
14:09 <Shiz> depends on the level of access the attacker has of course
14:42 <rfs613_> Shiz: I have been looking at http://chronox.de/jent.html
14:42 <rfs613_> I've run the test suite on the little Chromebox that gives me trouble with libressl (discussed here the other day).
14:45 <rfs613_> Next step is to get this thing to run, early during boot. I'll have to figure out how alpine's init works, haven't had time to tackle that yet ;-)
14:46 <rfs613_> skarnet: incidentally, you had mentioned that the libressl "fix" was no good... the author of the chronox.de agress with you ;-)
15:02 <TemptorSent> rfs613_: The jitterentropy provider should work, but still may take a minute or so to initilize a sufficient entropy pool.
15:06 <jirutka> is it possible to use OpenSMTPd with OpenDKIM or the only way is to use perl dkimproxy?
15:06 <consus> https://bbs.archlinux.org/viewtopic.php?id=213731
15:07 <consus> TL;DR dkimproxy
15:07 <jirutka> I’ve read that…
15:07 <jirutka> but it doesn’t answer my question
15:07 <jirutka> why OpenDKIM cannot be used with OpenSMTPd?
15:09 <consus> Hmm
15:09 <consus> https://github.com/oldsj/nsov/blob/master/smtpd.conf.j2
15:09 <rfs613_> TemptorSent: hmm, i was hoping it would be quick, but, haven't tested yet...
15:09 <consus> Seems like this guy runs it with opendkim
15:10 <consus> The only difference from the b.a.o is the port
15:10 <algitbot> https://bugs.alpinelinux.org
15:10 <consus> 10028 instead of 10027
15:11 <TemptorSent> rfs613_: The docs state it can fill 256 bits of entropy by the time it hits initfs, which isn't shabby actually. Still, it would be wise to force reseeding before doing anything with significant security implications.
15:12 <rfs613_> TemptorSent: I'll be content if SSH actually starts up on my little Chromebox, without me having to go plug in a keyboard and start typing.
15:12 <TemptorSent> rfs613_ It should do that.
15:13 <jirutka> consus: he has both OpenDKIM and dkimproxy in that repo
15:13 <rfs613_> TemptorSent: yep. I hope to try it soon.
15:13 <jirutka> consus: since it’s modified sovereign, I think that OpenDKIM is just a leftover
15:13 <Shiz> TemptorSent: 256 bits of entropy should be plenty
15:13 <consus> jirutka: Hmm
15:13 <Shiz> to support the entire system lifetime
15:13 <TemptorSent> rfs613_ : It appears the reseeding can be forced by simply writing to /dev/random
15:14 <consus> jirutka: Try #opensmtpd channel
15:14 <skarnet> 48 days later, they're still discussing "how to initialize entropy on a Linux box without a hwrng"
15:15 <skarnet> step 1: check in the OpenRC scripts whether there's a "save entropy" thing at shutdown time and a "restore entropy" thing at boot time
15:15 <skarnet> step 2: if there aren't such things, add them
15:15 <skarnet> step 3: ???
15:15 <skarnet> step 4: profit
15:15 <TemptorSent> I'd prefer to have 512 bits of entropy (2xDRNGs with independent pools), but that's asking a bit much.
15:16 <Shiz> skarnet: "How to generate entropy without HWRNG" - the greatest discussion in the history of #alpine-devel, locked by an op after 94,592 lines of heated debate
15:16 <jirutka> skarnet: there is such script in OpenRC, but when I tried it some time ago, it didn’t helped at all
15:16 <TemptorSent> skarnet: Doesn't save us in early boot for one, and the saved entropy itself is a potential vector if it's stored insecurely.
15:16 <skarnet> jirutka: it should help a little, if not 100%
15:17 <skarnet> TemptorSent: store it on a shared OneDrive account obviously
15:17 <TemptorSent> *LOL*
15:18 <Shiz> do what rust does with their ccache impl
15:18 <Shiz> store it in an s3 bucket
15:18 <TemptorSent> But for embedded, it's a real issue to consider.
15:18 <skarnet> embedded without a hwrng, without flash and without nvram is hopeless
15:18 <TemptorSent> Welcome to my world :)
15:19 <skarnet> I've always known you were hopeless
15:19 <Shiz> the solution is still not faking entropy
15:19 <Shiz> lol
15:19 <Shiz> be nice
15:19 <skarnet> sorry, lack of a smiley
15:19 <skarnet> :P
15:20 <TemptorSent> Agreed, the solution is finding what entropy we can as early as we can, which the cpujitter and interrupt timing can do.
15:20 <Shiz> im surprised cpu jitter timing is not part of mainline...
15:20 <skarnet> not sure how userspace egds work, but I'm surprised they disappeared
15:20 <TemptorSent> Basically, anything that tftp boots and doesn't have a HWRNG needs help.
15:21 <Shiz> skarnet: i'm not, really
15:21 <Shiz> i haven't seen any platform that wasn't able to initialise its hwrng pool within 1 min
15:21 <Shiz> in quite a while
15:21 <Shiz> err
15:21 <Shiz> rng pool*
15:21 <skarnet> until getrandom() started exposing bugs
15:22 <Shiz> what bugs
15:22 <Shiz> the one in libressl? :P
15:22 <Shiz> also fwiw
15:22 <skarnet> lack of proper entropy initialization before starting crypto, yeah
15:22 <Shiz> libressl getentropy() will likely still do the right thing
15:22 <Shiz> as it falls back to reading from /dev/urandom
15:22 <Shiz> which on early boot shouldn't be subject to fd exhaustion
15:23 <skarnet> the problem has never been fd exhaustion, that's a dalias windmill
15:23 <skarnet> the problem of /dev/urandom has always been early boot usage
15:23 <Shiz> ah, i thought it also blocked on early boot like getrandom()
15:23 <Shiz> my bad
15:24 <TemptorSent> That's the bug, it doesn't respect the entropy level and won't block if it's insufficient currently I believe.
15:24 <skarnet> exactly, and that's why getrandom() was added
15:24 <skarnet> lack of failure cases is just a bonus
15:25 <Shiz> right.
15:25 <TemptorSent> If clients handled getrandom() properly in nonblocking mode, they would have to wait until they got a valid value returned, which I don't believe they do.
15:25 <skarnet> that's called blocking mode :P
15:26 <skarnet> nonblocking mode is the exact same as reading /dev/urandom
15:26 <TemptorSent> Not necessarily, they could spin something or simply wait to start until after the pool is initilized
15:26 <TemptorSent> nonblocking mode returns EAGAIN IIRC if entropy is insufficient.
15:34 <jirutka> consus: I finally found some information https://crepererum.net/the-wonderful-world-of-e-mail/
15:35 <jirutka> consus: the problem is that OpenDKIM provides milter interface, but OpenSMTPD does not support milter interface
15:36 <jirutka> consus: and giles is not interested in writing one
15:36 <consus> =/
15:36 <jirutka> consus: he wrote that it can be implemented on top of OpenSMTPD’s simple filter interface, but apparently no one did it yet
15:36 <consus> Fun
15:37 <consus> How had is it to write one/
15:37 <jirutka> consus: you can try it, I’d be very glad for that :)
15:39 <consus> jirutka: Well
15:39 <consus> jirutka: As a subproject
15:39 <consus> jirutka: Why the hell not
15:49 <Shiz> jirutka: consus: the opensmtpd filter interfaces aren't stable yet
15:49 <Shiz> which is the show-stopper
15:50 <ncopa> build-3-6-ppc64le is done!
15:50 <Shiz> yay!
15:50 <ncopa> means we could have a rc1 soonish
15:52 <consus> ^^
15:53 cyteen joined
15:57 <ncopa> except that s390x is behind
15:57 <ncopa> and aarch64 is missing
16:04 <^7heo> Is printf(1) supposed to ignore --, by posix?
16:10 <TemptorSent> ^7heo Considering it doesn't accept flags, probably not.
16:10 <^7heo> Yet the busybox version does.
16:10 <TemptorSent> printf FORMAT [ARGS...]
16:10 <^7heo> yeah I can read.
16:10 <^7heo> :D
16:11 <TemptorSent> I'm seeing it working as expected with bb... "printf '%s\n' --"
16:12 <TemptorSent> What behavior are you seeing?
16:13 <^7heo> TemptorSent: try `printf -- foo`
16:13 <^7heo> TemptorSent: then try `printf -h foo`
16:14 <TemptorSent> Hmm, yeah - I see that behavior, but technically it's undefined behavior if the format string isn't valid I believe
16:15 <TemptorSent> Ahh, it still does it when quoted, yeah - that's a bug :)
16:16 <TemptorSent> File a bug report of 'printf(1) erronously parses flags in format argument position.'
16:17 <TemptorSent> Work around: "printf '%s--' ''"
16:22 <Shiz> TemptorSent: what does quoting have to do with it?
16:24 <TemptorSent> Hopefully nothing -- but it should keep the shell from eating things if that's what was happening -- it isn't, so it's a bug in printf itself.
16:28 <Shiz> ah
16:28 <Shiz> if the shell would eat that stuff that'd be a serious bug
16:28 <Shiz> on its own
16:29 <TemptorSent> Agreed :)
16:40 saintdev joined
16:40 <przemoc> POSIX's getopt() ends parsing when "--" is encountered (i.e. it returns -1), similarly with POSIX's getopts utility, therefore I would expect all POSIX-conformant tools to work properly with -- used as end of options marker. actually it's even clearly stated in Guideline 10 of Utility Syntax Guideline
16:40 <przemoc> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02
16:41 <przemoc> > The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.
16:41 jcloud joined
16:43 mjeanson joined
16:47 cyteen joined
16:59 cyteen joined
17:03 Mr_H joined
17:03 Mr_H joined
17:05 <Shiz> przemoc: yes, but printf doesn't take options
17:06 <Shiz> for every relevant utility in the spec, POSIX explicitly says "The awk utility shall conform to XBD Utility Syntax Guidelines ."
17:06 <Shiz> for awk, for instance
17:06 <Shiz> it does not for printf
17:07 Mr_H joined
17:10 Mr_H joined
17:11 Mr_H joined
17:20 <przemoc> Shiz: even if it is not explicitly stated in printf's OPTIONS section, I expect it to implicitly adhere to this guideline. it makes POSIX utilities's syntax simply more consistent. they explicitly state when -- shall not be recognized, like in case of echo.
17:20 <przemoc> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
17:20 ANSCH joined
17:20 <przemoc> > The echo utility shall not recognize the "--" argument in the manner specified by Guideline 10 of XBD Utility Syntax Guidelines; "--" shall be recognized as a string operand.
17:21 <Shiz> i think it's only explicitly mentioned there because implementations have a history of fucking up echo specifically
17:22 <Shiz> (e.g. bash echo builtin still violating it)
17:26 LouisA joined
17:31 <przemoc> check OPTIONS of Utility Description Defaults
17:31 <przemoc> http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap01.html#tag_23_01_05_04
17:31 <przemoc> > Although it has not always been possible, the standard developers tried to avoid repeating information to reduce the risk that duplicate explanations could each be modified differently.
17:31 <przemoc> > The need to recognize -- is required because conforming applications need to shield their operands from any arbitrary options that the implementation may provide as an extension. For example, if the standard utility foo is listed as taking no options, and the application needed to give it a pathname with a leading <hyphen-minus>, it could safely do it as: `foo -- -myfile` and avoid any problems
17:31 <przemoc> with -m used as an extension.
17:31 <skarnet> when the utility actually takes options.
17:32 <skarnet> when it doesn't, nothing is mentioned.
17:32 <skarnet> as Shiz says, echo is an exception.
17:33 <przemoc> please read Eric Blake's mail (guy from Austin Group) regarding it instead of insisting on your own view of the standard being the right one: https://lists.gnu.org/archive/html/bug-bash/2007-11/msg00118.html
17:35 <Shiz> przemoc: this is not the situation discussed above
17:35 <Shiz> and i realize that now :P
17:36 <Shiz> or rather
17:36 <Shiz> i misinterpreted the situation discussed
17:38 <Shiz> it seems you're right
17:52 <przemoc> I was only responding to ^7heo> Is printf(1) supposed to ignore --, by posix? tl;dr is: yes as long as it used before operands
17:54 <przemoc> s/as it/& is/
17:56 <skarnet> meh. After reading everything again, it appears you're right.
17:57 <skarnet> Can't say I like it, but I understand the reasoning behind it.
17:57 <skarnet> (the choice to always handle --, that is)
17:59 <przemoc> well, it makes life easier and strives for consistent behavior, and I prefer consistency over stubborn minimalism. in this particular case POSIX has my approval. :)
18:00 <skarnet> yes - for a given implementation it wouldn't make any sense, but for standard commands that may be extended, it does
18:04 <TemptorSent> In the case of a command which doesn't process ANY flags, it should not swallow --.
18:07 <TemptorSent> (And the IEEE 1003.1-2008, 2016 edition says nothing about parsing '--' nor conforming with Guideline 10 of XBD - nor does it say it DOESN'T, which is a bug in the standard :) )
18:10 <TemptorSent> So absent the reference to XBD Utility Syntax Guidelines, and taking into account that it explicitly intends to replace functionality of echo, it appear printf should NOT handle anything with a leading - in any special manner in any case whatsoever.
18:10 <przemoc> I won't repeat myself, you can check the sources I provided or remain stubborn in thinking you know better. if standard repeated everything everywhere it would be twice as large.
18:10 <TemptorSent> I'm looking at the POSIX standard itself.
18:11 <TemptorSent> In all other utilities it references the XBD Utility Syntax Guidelines
18:12 <TemptorSent> such as 'The awk utility shall conform to XBD Utility Syntax Guidelines' under the OPTIONS heading for awk, whereas printf has NO options.
18:12 <skarnet> you will excuse me for not staying any longer.
18:12 skarnet left
18:15 <TemptorSent> przemoc: If no options are to be parsed, it is a bug to parse strings as options.
18:15 <TemptorSent> If printf did not EXPLICITLY state that it accepts no options, I would be in agreement.
18:17 <przemoc> C. Rationale for Shell and Utilities > C.1.5 Utility Description Defaults > This section is arranged with headings in the same order as all the utility descriptions. It is a collection of related and unrelated information concerning: 1. The default actions of utilities 2. The meanings of notations used in POSIX.1-2008 that are specific to individual utility sections. Although this material may seem
18:17 <przemoc> out of place here, it is important that this information appear before any of the utilities to be described later. <- you should read it BEFORE reading any description of particular utilities, and there you have OPTIONS section which I already quoted and explains why -- must be supported (otherwise it is explicitly stated in utility description, of course)
18:21 <TemptorSent> przemoc: This interpretation breaks the ability to replace echo with printf as is explicitly intended by the standard.
18:21 <TemptorSent> So the standard is ambiguous for printf
18:24 <TemptorSent> Printf does not accept filenames, and uses all agruments verbatim, so there is no case where '--' could conceivably be required for proper operation, wheras using it as a format may be common (sql comments for instance start with '--')
18:25 <TemptorSent> To have printf act as expected in all cases, it would require it always be called as "printf -- FORMAT [ARGS...]
18:26 <przemoc> it doesn't matter what printf accepts. what part of "The need to recognize -- is required because conforming applications need to shield their operands from any arbitrary options that the implementation may provide as an extension." you fail to understand?
18:27 <TemptorSent> Here's an example of breakage: a="-- Comment" ; b="--" ; printf $a ; printf $b
18:28 <TemptorSent> printf may not accept options.
18:28 <TemptorSent> That's why it was created - to replace echo, which sometimes accepts options.
18:29 <TemptorSent> Read the rationale section for printf
18:30 <TemptorSent> To disambiguate, the standard either needs to explicitly state that -- will be handled and how, or explicitly state that it shall not.
18:32 <TemptorSent> Having behavior inconsistent with the definition of echo is counter to the stated rationale.
18:35 <TemptorSent> Theoretically, you should never have a format string without a format specifier, and all strings should be handled through that.
18:36 <przemoc> implementation of utility w/o options in POSIX may have options (it's called extension and such things exist in real world) and standard already explains in Rationale for Shell and Utilities that -- needs to be handled because of that. therefore yes, you should `printf -- ...` if you want to support displaying -- when -- is provided as FORMAT string. the problem w/ echo is that it does not support
18:36 fekepp joined
18:36 <przemoc> -- and different implementations provided their own options so behavior was incosistent, as some implementations treated options as stuff that should be printed
18:36 <TemptorSent> so "printf '%s' '--'"
18:37 <TemptorSent> Basically, it means that there is a single format specifier that is unsupported, namely '--'
18:39 <TemptorSent> Which is unintuitive and leads to unexpected behavior.
18:40 <TemptorSent> The standard should explicitly state that no options shall be supported and -- is not handled for the most consistent behavior.
18:41 <TemptorSent> Or at least document the fact that it should be called as "printf -- FORMAT [ARGS...]" in order to support ALL possible format strings.
18:45 <przemoc> no, if you want to use -- as FORMAT, you simply need to use additional -- before such operand. simply use `printf -- ...` if you want to avoid any problems, but please note that their example in echo's APPLICATION USAGE works as expected even for single --
18:48 <przemoc> I can agree that they could add a note regarding options in printf, but I don't think it's truly necessary, as it's repeating what is already stated in other place
19:09 <TemptorSent> IMHO, ambiguity should always be clarified, as it is in and of itself an error in logic for deterministic outcomes.
19:11 <TemptorSent> But this actually explains why some SQL template code with comments was causing problems (used as the format string containing format specs to be filled before processing)
19:12 <TemptorSent> So 'printf --' should be used EVERY time a variable format spec is used.
19:13 <TemptorSent> As the implication is that no leading '-' in a format spec is actually safe.
19:14 <TemptorSent> So it needs a note stating that much at the very least.
19:17 <TemptorSent> At minimum, currently there's at minimum a documentation bug in POSIX, and possibly a truly ambiguous definition.
19:19 <TemptorSent> Either '--' is required before ANY format argument starting with a leading '-' for portable use, or '--' should not be parsed and such should be noted.
19:19 <TemptorSent> Otherwise, we're back to the exact same problem as echo.
19:23 <TemptorSent> (previous comment from the department of redundancy department :) )
19:24 <TemptorSent> Heading into town, be back in a few hours.
19:27 blueness joined
19:32 <jirutka> Shiz: OpenSMTPD filter interface is very simple, so even if not stable, there should not be any barrier for implementing milter adapter
19:33 <jirutka> Shiz: and it’s at least already in released version and documented, I’ve started using OpenSMTPD filters even before that, when gilles refused to provide any documentation to encourage ppl from using it…
19:34 FilippAndronov joined
19:36 <jirutka> Shiz: I used to idle on opensmtpd IRC channel few years ago and from what I’ve seen, when gilles say that something is not ready yet and stable, it just means that he’s not 100% sure yet that there are not any memory leaks or similar issue :) he’s perfectionist about that
19:45 blueness joined
19:54 <przemoc> you should always use -- before operands if first operand may start with -, unless utility doesn't support --. but any normal and sane utility does support it, be it binary program or shell script. -- as end of options became de facto standard in *nix world decades ago
20:22 tmh1999 joined
20:50 tmh1999 joined
22:08 tmh1999 joined
22:09 cyteen joined
22:24 minimalism joined
22:37 tmh1999 joined
23:24 tmh1999 joined
23:51 blueness joined
23:52 tmh1999 joined