Re: [dev] dmenu-4.4
On 07-19 21:48, Connor Lane Smith wrote: tarball: http://dl.suckless.org/tools/dmenu-4.4.tar.gz Thanks for all. Could the releasers please start providing checksums (or PGP signatures) for releases? Now that'd be great.. -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [dev] dmenu-4.4
On 20 July 2011 09:43, ilf i...@zeromail.org wrote: Could the releasers please start providing checksums (or PGP signatures) for releases? Might it be satisfactory to just supply some sort of DNS level security and/or use HTTPS? I dunno. I just know PGP checksums are a bit painful to say the least.
Re: [dev] dmenu-4.4
On 07-20 10:20, Kai Hendry wrote: Might it be satisfactory to just supply some sort of DNS level security and/or use HTTPS? I dunno. Both HTTPS and SHA(1|256) shouldn't really be a problem. -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [dev] dmenu-4.4
On 20 July 2011 10:41, ilf i...@zeromail.org wrote: On 07-20 10:20, Kai Hendry wrote: Both HTTPS and SHA(1|256) shouldn't really be a problem. You mean HTTPS download and publishing the SHA somewhere? publishing the SHA sounds crappy to me. How do you do it? In a wiki? In a text file? All suck. HTTPS I can _just_ about live with, but that's crappy too really. Anyone can get a HTTPS cert, so how can you test sanely that it indeed came from suckless when sucking it down with curl? Surly it's more of a DNS thang we need to rely on?
Re: [dev] dmenu-4.4
On Wed, Jul 20, 2011 at 10:47:28AM +0100, Kai Hendry wrote: HTTPS I can _just_ about live with, but that's crappy too really. Anyone can get a HTTPS cert, so how can you test sanely that it indeed came from suckless when sucking it down with curl? Surly it's more of a DNS thang we need to rely on? Why isn't PGP signing the answer here? You can continue to serve from a simple, insecure connection, without having to pretend that HTTPS' trust model is not broken, and can verify the download perfectly. wget http://dl.suckless.org/tools/dmenu-4.4.tar.gz wget http://dl.suckless.org/tools/dmenu-4.4.tar.gz.sig gpg --verify dmenu-0.4.tar.gz.sig is not that tricky.
Re: [dev] dmenu-4.4
On 20 July 2011 10:54, Nick suckless-...@njw.me.uk wrote: wget http://dl.suckless.org/tools/dmenu-4.4.tar.gz.sig gpg --verify dmenu-0.4.tar.gz.sig is not that tricky. You've skipped over the part of how you exchange the public key, no? If it's not that tricky why doesn't Arch for example build it in to their tools? And btw gpg sucks big time. :)
Re: [dev] dmenu-4.4
On Wed, Jul 20, 2011 at 10:58:32AM +0100, Kai Hendry wrote: On 20 July 2011 10:54, Nick suckless-...@njw.me.uk wrote: wget http://dl.suckless.org/tools/dmenu-4.4.tar.gz.sig gpg --verify dmenu-0.4.tar.gz.sig is not that tricky. You've skipped over the part of how you exchange the public key, no? That is true, yes, good point. But just downloading the key from a keyserver, even if it isn't trusted by your web of trust, is better than e.g. just distributing a hash, and as mentioned trusting CAs (HTTPS) is pretty problematic. If it's not that tricky why doesn't Arch for example build it in to their tools? I know very little of Arch's processes, so I can't say. And btw gpg sucks big time. :) Alas yes, but it does work well.
Re: [dev] dmenu-4.4
On 20 July 2011 11:06, Nick suckless-...@njw.me.uk wrote: But just downloading the key from a keyserver, even if it isn't trusted by your web of trust, is better than e.g. just distributing a hash, and as mentioned trusting CAs (HTTPS) is pretty problematic. Why is a random keyserver more trustworthy than a run-of-the-mill CA? Still even if it is more trustworthy (which I doubt), introducing the GPG tool chain for that marginal gain (if any), is extremely sucky. I still think DNSSEC might help, though tbh I don't know anything about it and I'm grasping at straws. Cue someone clueful to say why DNSSEC is not the answer. ;)
Re: [dev] dmenu-4.4
On 07-20 10:47, Kai Hendry wrote: publishing the SHA sounds crappy to me. How do you do it? In a wiki? In a text file? All suck. In the mail with the release announcement. HTTPS I can _just_ about live with, but that's crappy too really. Of course X.509 is broken and everything sucks, but it's what we have to live with. And better than nothing. -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [dev] dmenu-4.4
On 20 July 2011 11:11, ilf i...@zeromail.org wrote: In the mail with the release announcement. checksums in the announcement is something as a package maintainer you can't automate and has to be manual and hence sucks. Of course X.509 is broken and everything sucks, but it's what we have to live with. And better than nothing. So would you be happy just with HTTPS and not checksums I wonder?
Re: [dev] dmenu-4.4
On Wed, Jul 20, 2011 at 10:58:32AM +0100, Kai Hendry wrote: On 20 July 2011 10:54, Nick suckless-...@njw.me.uk wrote: wget http://dl.suckless.org/tools/dmenu-4.4.tar.gz.sig gpg --verify dmenu-0.4.tar.gz.sig is not that tricky. You've skipped over the part of how you exchange the public key, no? Just upload it to suckless.org and/or some key servers. If it's not that tricky why doesn't Arch for example build it in to their tools? pacman 4.0.0 will support package signatures and we'll sign all packages in the official repos ([core], [extra], [community]) soon. And btw gpg sucks big time. :)
Re: [dev] dmenu-4.4
On 20 July 2011 11:06, Nick suckless-...@njw.me.uk wrote: But just downloading the key from a keyserver, even if it isn't trusted by your web of trust, is better than e.g. just distributing a hash, [...] The concept of PGP trust lies in the Web-of-Trust, nowhere else. If you don't find a trust-path from you to the signing key, then the signature does only provide the information of a checksum hash. meillo
Re: [dev] dmenu-4.4
On 07-20 11:16, Kai Hendry wrote: In the mail with the release announcement. checksums in the announcement is something as a package maintainer you can't automate and has to be manual and hence sucks. I believe the mail that started this thread is not automated. Also I fail to see where package meintainers are involved. Of course X.509 is broken and everything sucks, but it's what we have to live with. And better than nothing. So would you be happy just with HTTPS and not checksums I wonder? No :) -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [dev] dmenu-4.4
On 20 July 2011 11:06, Lukas Fleischer suckl...@cryptocrack.de wrote: pacman 4.0.0 will support package signatures and we'll sign all packages in the official repos ([core], [extra], [community]) soon. Debian IIRC just signs the package lists (including checksums) in practice, which is fine. I hope there isn't going to be a .sig for every .pkg.xz because that would suck. Still this is besides the point. We were trying to work out how suckless delivers the package, not Arch. So to be getting back to the point, I would like to know how Arch can securely make sure it's downloading the correct package. I know it has the md5 construct in the PKGBUILD which I am not that keen about since it's manual, breaks often and sucks etc.
Re: [dev] dmenu-4.4
On 20 July 2011 11:32, ilf i...@zeromail.org wrote: Also I fail to see where package meintainers are involved. Lets pretend I'm the package maintainer for Debian and I need to ensure that the dmenu I download indeed came from suckless and was not tampered with. So would you be happy just with HTTPS and not checksums I wonder? No :) Awww! I was next going to suggest an etag or something, but that doesn't work. hendry@x201 ~$ curl -I http://dl.suckless.org/tools/dmenu-4.4.tar.gz HTTP/1.1 200 OK Content-Type: application/octet-stream Accept-Ranges: bytes Content-Length: 9308 Date: Wed, 20 Jul 2011 11:00:04 GMT Server: lighttpd/1.4.19 Surprised we're running lighttpd tbh. I thought garbeam liked nginx. Regards,
Re: [dev] dmenu-4.4
On Wed, Jul 20, 2011 at 12:32:32PM +0200, markus schnalke wrote: On 20 July 2011 11:06, Nick suckless-...@njw.me.uk wrote: But just downloading the key from a keyserver, even if it isn't trusted by your web of trust, is better than e.g. just distributing a hash, [...] The concept of PGP trust lies in the Web-of-Trust, nowhere else. If you don't find a trust-path from you to the signing key, then the signature does only provide the information of a checksum hash. Yes. I was being slightly unreasonable in saying it was better. I only meant it's like a hash with benefits, e.g. it does hashing, plus verification if you want / need it.
Re: [dev] dmenu-4.4
On Wed, Jul 20, 2011 at 7:02 AM, Kai Hendry hen...@iki.fi wrote: Lets pretend I'm the package maintainer for Debian and I need to ensure that the dmenu I download indeed came from suckless and was not tampered with. Why? If you're a package maintainer for Debian you're just going to tamper with it anyway. Why should you have all the fun? Can we please let this ridiculous non-issue drop? If you really need to get it out of your system, maybe you can find a security theatre mailing list where this rambling garbage would be on-topic. -- # Kurt H Maier
Re: [dev] dmenu-4.4
On Wed, 20 Jul 2011 11:06:37 +0100 Nick suckless-...@njw.me.uk wrote: as mentioned trusting CAs (HTTPS) is pretty problematic. This is more problematic, because there is no clear way of knowing which CAs your browser trust e.g. removing CNNIC (China Internet Network Information Center) doesn't help at all. CA can have child CA and child CA can have another child and so on. Just check map [1] of trusted CAs by Mozilla or Microsoft to get idea. SSL Observatory project [2] has found some interesting facts about HTTPS authentication model. [1] https://www.eff.org/files/colour_map_of_CAs.pdf [2] http://www.eff.org/observatory -- Paul Onyschuk bl...@bojary.koba.pl
Re: [dev] dmenu-4.4
Why not just have a quick once-over of the code? There's a reason suckless apps aim to be under a certain SLOC limit, and I take it that one of these is so that one can have a quick once-over of the code. And if the distro maintainer can't do this, so much the worse for the distrubition. Peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
[dev][dwm] Floating window center position fix
I have a rule in config.h for MPlayer to always float. The bug was
observed when I played a 720p video whose window was 1280 pixels so it
filled the width of my laptop screen. The MPlayer window was supposed to
be centered, but a border line on the left was clearly visible. For
further confirmation, I set borderpx to 20. My observation was obviously
right. The patch is appended at the end.
Another thing I've observed but didn't care to fix when playing the video:
If the MPlayer window is always created in tag 4 (as per a rule), but I
run the mplayer command in xterm in tag 1, the visibility of the MPlayer
window border depends on some timing:
1) If I switch from tag 1 to tag 4 _after_ the MPlayer window is created,
the border is visible.
2) If I switch from tag 1 to tag 4 _before_ the MPlayer window is created,
the border is invisible. It seems for dwm the border exists, just not
drawn. If I switch to another tag and back, or do a focusstack()
using the default mod1+j combo or pretty about anything, the border
will then be drawn.
Relevant entries in my test config.h are:
static const unsigned int borderpx = 20;
static const Rule rules[] = {
{ MPlayer, NULL, NULL, 1 3, True, -1 },
};
And following is my patch for the center position bug:
Patch for dwm 5.9
diff -up a/dwm.c b/dwm.c
--- a/dwm.c 1970-01-01 00:00:00.0 +
+++ b/dwm.c 1970-01-01 00:00:00.0 +
@@ -624,9 +624,9 @@ configurerequest(XEvent *e) {
if(ev-value_mask CWHeight)
c-h = ev-height;
if((c-x + c-w) m-mx + m-mw c-isfloating)
- c-x = m-mx + (m-mw / 2 - c-w / 2); /*
center in x direction */
+ c-x = m-mx + (m-mw / 2 - WIDTH(c) / 2); /*
center in x direction */
if((c-y + c-h) m-my + m-mh c-isfloating)
- c-y = m-my + (m-mh / 2 - c-h / 2); /*
center in y direction */
+ c-y = m-my + (m-mh / 2 - HEIGHT(c) / 2); /*
center in y direction */
if((ev-value_mask (CWX|CWY)) !(ev-value_mask
(CWWidth|CWHeight)))
configure(c);
if(ISVISIBLE(c))
Re: [dev] dmenu-4.4
On Wed, Jul 20, 2011 at 11:32:25AM -0400, Peter John Hartman wrote: Why not just have a quick once-over of the code? There's a reason suckless apps aim to be under a certain SLOC limit, and I take it that one of these is so that one can have a quick once-over of the code. And if the distro maintainer can't do this, so much the worse for the distrubition. Very true, Peter.
Re: [dev][dwm] Floating window center position fix
Hi lolilolicon,
On 20 July 2011 17:53, lolilolicon loliloli...@gmail.com wrote:
I have a rule in config.h for MPlayer to always float. The bug was
observed when I played a 720p video whose window was 1280 pixels so it
filled the width of my laptop screen. The MPlayer window was supposed to
be centered, but a border line on the left was clearly visible. For
further confirmation, I set borderpx to 20. My observation was obviously
right. The patch is appended at the end.
Thanks, applied.
Another thing I've observed but didn't care to fix when playing the video:
If the MPlayer window is always created in tag 4 (as per a rule), but I
run the mplayer command in xterm in tag 1, the visibility of the MPlayer
window border depends on some timing:
1) If I switch from tag 1 to tag 4 _after_ the MPlayer window is created,
the border is visible.
2) If I switch from tag 1 to tag 4 _before_ the MPlayer window is created,
the border is invisible. It seems for dwm the border exists, just not
drawn. If I switch to another tag and back, or do a focusstack()
using the default mod1+j combo or pretty about anything, the border
will then be drawn.
Relevant entries in my test config.h are:
static const unsigned int borderpx = 20;
static const Rule rules[] = {
{ MPlayer, NULL, NULL, 1 3, True, -1 },
};
Thanks for your bug report, this needs further investigation.
Cheers,
Anselm
Re: [dev] [dwm] [bug] 5.9's first bug: magic float mode
Hi Peter,
On 11 July 2011 01:02, Peter John Hartman peterjohnhart...@gmail.com wrote:
Actually, this bug goes way back, but I thought I'd be the first to report
it, just to ruin dwm's birthday. The culprit is this chunk of code in
manage():
if(c-w == c-mon-mw c-h == c-mon-mh) {
// c-isfloating = True; pjh
c-x = c-mon-mx;
c-y = c-mon-my;
c-bw = 0;
}
Commenting out that line fixes it.
How you reproduce it is the fun bit.
(1) You have to have borderpx set to 0.
(2) You have to be in monocle mode.
[(3) You might also have to have statusbar hidden.]
(4) Open up a couple of apps.
Now, hit MODKEY+Shift+q, provided you have the dwm loop thing in your
.xinitrc. The windows all come back in floating mode, lovely enough.
Thanks for spotting. I applied it despite the fullscreen rework plans for now.
Current discussion on the mailing list is leaning to just eliminating that
chunk of code. Apparently, flash fullscreen requires it (which I haven't
been able to reproduce!) But why on earth is that code there, and can't
flash fullscreen be handled via a Rule?
I need to investigate when I added this chunk of code to remember why :)
Cheers,
--garbeam
Re: [dev] Re: dwm aesthetic 'bug'
On 19 July 2011 17:49, Connor Lane Smith c...@lubutu.com wrote: And here's a usability bug. (I don't have a patch for this one.) If you have the following clients: A (tag 1) B (tag 2) C (tags 1,2) Whenever you switch from tag 1 to 2, client C will *always* be focused, even if it your last two focused clients were A and B. It seems that dwm chooses to focus C because it's common to both tags, even though it ought to be at the bottom of the focus stack. This results in me having to refocus A or B *every time* I switch tag. That seems broken to me. This is annoying indeed, I'm thinking about a good solution. Cheers, Anselm
Re: [dev] dwm aesthetic 'bug'
On 12 July 2011 15:34, Connor Lane Smith c...@lubutu.com wrote: I noticed a slight aesthetic 'bug' in dwm's tile layout, which can cause the stack to 'shake' when your master changes, if your config.h respects resizehints, because it uses c-w instead of mw. Patch attached. (If I'm honest I don't know what corner case the inline ifs are for.) Thanks, applied. --garbeam
Re: [dev] dmenu-4.4
I think we should send the suckless van to the sender and raid their homes to authenticate the release. I feel like I can't be sure who I'm talking to on this mailing list any more. Everyone show their ids now or I will call the police!
Re: [dev] dmenu-4.4
On 20 July 2011 10:43, ilf i...@zeromail.org wrote: On 07-19 21:48, Connor Lane Smith wrote: tarball: http://dl.suckless.org/tools/dmenu-4.4.tar.gz Thanks for all. Could the releasers please start providing checksums (or PGP signatures) for releases? We coped very well without it for many years, why is the lack of md5 files a concern now? Anyhow, I'm fine to create md5 files for all downloadable tar.gz's that you can check the integrity. If you don't trust our DNS records, I don't intend to go this PGP signing route... Cheers, Anselm
Re: [dev] dmenu-4.4
On 07-20 20:52, garbeam wrote: Could the releasers please start providing checksums (or PGP signatures) for releases? We coped very well without it for many years, why is the lack of md5 files a concern now? I always wondered if this had been discussed and rejected or just never thought about. Seems pretty helpful for some basic verification. Also seems good practive in the FLOSS world. Plus there have been cases of pwned and backdoor'd FLOSS repositories/releases. Anyhow, I'm fine to create md5 files for all downloadable tar.gz's that you can check the integrity. Cool! Tough SHA(1|256) seem more reasonable to me. :) -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [dev] dmenu-4.4
On 20 July 2011 09:43, ilf i...@zeromail.org wrote: Could the releasers please start providing checksums (or PGP signatures) for releases? We do use Mercurial, which creates a hash for each revision. So if this matters to you, clone the repository and checksum the contents? cls
Re: [dev] dmenu-4.4
On 20 July 2011 21:11, ilf i...@zeromail.org wrote: On 07-20 20:52, garbeam wrote: Could the releasers please start providing checksums (or PGP signatures) for releases? We coped very well without it for many years, why is the lack of md5 files a concern now? I always wondered if this had been discussed and rejected or just never thought about. Seems pretty helpful for some basic verification. Also seems good practive in the FLOSS world. Plus there have been cases of pwned and backdoor'd FLOSS repositories/releases. Anyhow, I'm fine to create md5 files for all downloadable tar.gz's that you can check the integrity. Cool! Tough SHA(1|256) seem more reasonable to me. :) Well, what you get is this from now on: http://dl.suckless.org/dwm/md5sums.txt http://dl.suckless.org/dwm/sha1sums.txt This can also be found in other directories. I hate having a sum file per tar.gz... Cheers, --garbeam
Re: [dev] [dwm] [bug] 5.9's first bug: magic float mode
On Wed, Jul 20, 2011 at 8:39 PM, garbeam garb...@gmail.com wrote: Current discussion on the mailing list is leaning to just eliminating that chunk of code. Apparently, flash fullscreen requires it (which I haven't been able to reproduce!) But why on earth is that code there, and can't flash fullscreen be handled via a Rule? I can reproduce that fullscreen flash requires this. Flash creates a new window with unknown title and class and sets the _NET_WM_FULLSCREEN property. Maybe as a solution it makes sense to check for _NET_WM_FULLSCREEN property in manage() and set c-isfullscreen (and modify some layout functions). I stumbled on an old mailinglist post about this subject: http://permalink.gmane.org/gmane.comp.misc.suckless/2094 . --- Kind regards, Hiltjo
Re: [dev] [dwm] [bug] 5.9's first bug: magic float mode
I can reproduce that fullscreen flash requires this. Flash creates a new window with unknown title and class and sets the _NET_WM_FULLSCREEN property. Maybe as a solution it makes sense to check for _NET_WM_FULLSCREEN property in manage() and set c-isfullscreen (and modify some layout functions). I stumbled on an old mailinglist post about this subject: http://permalink.gmane.org/gmane.comp.misc.suckless/2094 . Ok, I can agree that flash fullscreen window is unknown, but does it *require* this? I've been watching flash without that line for weeks. Of course, if you *want* flash to float (for whatever god-forsaken reason) then you'll have a hard time making it float, but why would you want this? Maybe I'm wrong, but I can't reproduce a problem with flash in fullscreen mode that this line of code would fix. Peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
Re: [dev] dmenu-4.4
On Tue, Jul 19, 2011 at 4:48 PM, Connor Lane Smith c...@lubutu.com wrote: I've just released dmenu-4.4. It fixes some bugs and it should be slightly nippier, especially if your path is, ahem, broken. (Hopefully there won't be 4.4.1! :p) The only issue I have with the latest release is the file name 'lsx'. It's already taken. On Slackware it is a symlink to /usr/bin/lsz. Other people might use 'lsx' as an ls alias of some sorts. Perhaps ls-x, lsexec, lsex, or dmenu-lsx would work better? I figured the latter would be least desirable since the program is likely intended to be used by other programs than dmenu. If everyone else likes it as is, then I'll just have to make some changes before packaging dmenu for Slackware. --phillip
Re: [dev] dmenu-4.4
On 21 July 2011 02:19, Phillip Warner phillip.c.war...@gmail.com wrote: The only issue I have with the latest release is the file name 'lsx'. It's already taken. Hmm, that's unfortunate, but lsx has been named that since 2006 [1], and some greedy alias is just annoying. That one package claims lrb, lrx, lsb, lsx, rb, rx, rz, sb, sx, and sz, just for symlinks? Jesus. Other distros appear to be fine, so I don't think it's really our problem. [1]: http://tools.suckless.org/lsx Thanks, cls
