Entries tagged rants

Randomisation is a good thing for media players, but it must be done properly.

What do I mean by this? I mean randomness which only works going forwards.

As an example consider the case where you have several films/videos in a directory and you run this:

xine --loop=shuffle *.mpeg *.avi

This appears to do what you want, showing each film in a random order but it is subtly doing the wrong thing.

If you're watching film "two", having just finished film "five" you'd expect to be able to return to film "five" by pressing "previous"/Page-Up - however that doesn't happen.

Xine decides that "moving backwards" in the playlist means selecting another film at random, rather than the previously viewed film which was selected at random - the two are different - and the current behaviour is both counter-intuitive and plain wrong IMHO.

I forget the name of the media player that I used briefly which also behaved like this, but it was enough to make me abandon it almost immediately.

So, think of the children. If you have a random mode, make sure that going to previous items actually does return to previously played items and not random ones.

Tags: randomness, rants, shuffling, xine | No comments

Previously I wrote about two "bugs" with GNU Screen.

Now I discover, via a customer, that one of the servers I setup had allowed shell access when it should have been prohibited. A potentially serious security hole in this context.

Here is an example, with this small .screenrc file:

#
#  Normally "ctrl-a c" would open a new "window".
#
#  We wish to prohibit that
#
bind c

Start GNU screen. Press "Ctrl-a c" nothing happens. All looks well, you've denied a new window! If you'd setup a shell in /etc/passwd to point to a wrapper which invoked GNU Screen with this configuration file you'd be fine, right?

Actually not. Try pressing "Ctrl-a" and whilst those two keys are held down press and release "c". Joy. New window created. Even though it shouldn't be.

Update - Turns out I'm stupid "ctrl-a c" is the same as "ctrl-a ctrl-c" by default. I didn't add "bind ^c" appropriately. My bad.

For reference if you want to stop shell creation and you invoke screen as a login shell as a wrapper for other things then you must unbind a lot of builtins. eg. "bind :". You should then set:

shell /bin/false

Only then will you be secure. Probably.

Thankfully this doesn't affect the Xen shell.

Tags: false alarm, gnu screen, rants, screen | No comments

Today I've been mostly unwell. Although I have managed to write some minor new code, and watch a little bit of Doctor Who on DVD.

Recently several people have been ranting about Ruby on Rails. I like it, but I wouldn't use it for personal development in a hurry. Deployment is fiddly, and upgrades are annoying.

But one thing that I utterly condemn Rails for is helping to spread bad paging throughout the online world.

So, what is "bad paging" and why is it important? Well cool URLs don't change, right? "Bad paging" is any user-interface which presents you with a limited view upon a changing list of items which is non-bookmarkable.

Consider the following "list". Assume it represents your view of a collection of items numbering 100+. You may only view ten items at a time; clicking "next", or "previous", to navigate your viewport:

1.  first item
2.  second item
..
10. tenth item

[see next: /start/1] [see prev]

Whats wrong with this picture? It is subtle, but this list is broken. The issue is that when the list grows new items are prepended to the front, yet the navigation is linked to the starting page number.

If that description wasn't clear consider what happens if you want to bookmark the page containing item 11. How can you?

Right now it is at /start/1. If a ten new items are appended to the head of the list then it will instead become /start/2 - as items that are currently numbered 1-10 will be shifted forward to become items 11-20, and and they will be on page /start/1 instead.

The solution is simple enough once you consider what you want to happen:

• Either append items to the end of the list.
  • Such that /start/1 always gives the items 11-20.
• Number the links in the reverse order.

So why does nobody do that? (As a counter example look at my website: Rather than the 'Show previous' items linking you to the changing link /start/1, it instead links you to /start/569 (for example).

Tags: paging, random, rants | 2 comments

So, as I previously mentioned I want to be able to tag messages in Mutt.

There exist folder-based solutions already, using the X-Label header. There doesn't appear to be any existing solution allowing you to view all messages with a given tag across mailboxes.

So I wrote a simple shell script to create virtual mailboxes, such as ~/Maildir/tags-debian for all messages with a debian tag, using hardlinks.

My conclusion is that this solution will not work properly in practise, primarily because of deficiencies in mutt.

The simple case works just fine. I add a tag to a message, and later when the indexing job runs the virtual folder is created. I can open it and work on it just fine.

So where's the problem? Well in my case I tend to tag messages with a label such as "todo". Once I've done whatever I was supposed to I can remove the tag.

Using this hardlinking scheme I cannot remove the tag(s) in the virtual folder - I have to remove it in the original message which is a real pain.

Why? Well quite simply mutt will not let me work on my virtual message without destroying the hardlink.. If I use the edit function, for example, I am presented with a copy of the mail for editing - and the hardlink is replaced when that copy is saved.

Even the edit-label patch which allows you to edit the X-Label header from within mutt ends up replacing the hardlink with a new file!

So whats the solution? Well I guess I want to be able to run an external command against a message in mutt - passing the filename of the Maildir message as an argument. That way I can edit the live file.

Right now I don't believe that is possible, but I'd love to be told different.

If anybody has any solutions of editing, or even just deleting, a header from a message within mutt - in such a way that the hardlink isn't destroyed please do let me know.

Simple reproducer:

mkdir -p ~/Maildir/.foo/cur
mkdir    ~/Maildir/.foo/new
mkdir    ~/Maildir/.foo/tmp
cp 'validmessage' ~/Maildir/
ln validmessage ~/Maildir/.foo/cur

Now edit the message - start mutt open the message in the index and press 'e' - the hardlink is now gone. Replaced by a new file with the contents, so the original mail message is unchanged.

Update: I've got an "edit-inplace" primitive working, via the very hacky header-fu patch. It is not complete, but it demonstrates that it can be done. My world is now complete.

Tags: mutt, rants, tags | 7 comments

If you upload a new package to the Debian archive which contains a setuid or setgid binary please please ask for a security audit, or carry out one yourself.

I certainly accept that the security audit project webpages are not terribly current, and the mailing list is essentially dead, but there are people, such as myself, who would gladly look at your package. All you have to do is ask.

When I see two packages in testing with trivialy obvious security bugs it just makes me wonder why we bother.

• tss
  • tss: local root exploit
  • tss: Allows reading arbitary files
• acon
  • #475733 acon: local root exploit

I'm going to take this chance to restate my hardline position on package maintainence - even though it might not be directly applicable - If you cannot program/debug/handle the language a package is developed in you shouldn't maintain it.

Too often I've seen signs of this; somebody maintaining a C-based program but unable to program in C. Why?

I wonder if we could have a policy / guideline that any new setuid/setgid application must have at least two maintainers, or a documented audit prior to acceptance? Hard to manage but I think it would be useful even if it didn't catch everything. Some bugs such as #475747 (lovely number!) are trivial to discover.

ObQuote: Dangerous Liaisons

Tags: rants, security | No comments

ObRandom:

Any blog post, comment thread, question, or email which starts "Hi guys" is bad, wrong, and probably not worth reading.

ObTitle: Dawn of the dead - the original and best version - 1978

Tags: random, rants, sexism | 4 comments

I could argue and make reasonable points - but instead I'm going to be childish/annoying/ignorant/confrontational/blunt:

SELinux sucks.

If I wanted a rational debate I'd approach the topic differently - this is a clue that you shouldn't attempt to convert me.

I got distracted during the "Should selinux be standard? thread, so I will optimistically assume it will not be. Why? Because SELinux is annoying to configure if you understand it, and pointless if you don't.

ObFilm: From Dusk Til Dawn

Tags: lenny, rants, selinux | 4 comments

Too often requests of the form "I'm looking for an open source solution to ..." mean "I'm looking to spend zero money, contribute nothing, and probably not even read your excellent documentation".

Tags: rants | 2 comments