Thursday, 28 March 2013

The sorry state of the Android universe


Update: Corrected the code name for 4.2.2 is Jelly Bean, not Ice Cream Sandwich as I initially stated. I also described in the comments why the calendar application is also crap.

I recently bought a phone based on the Android platform (version 4.2.2 aka Jelly Bean). Before the purchase I had the wrong idea that this platform - Android - is the best thing since sliced bread. Let me tell you, that idea is so wrong, it's a shame anybody thinks or has ever thought that.

My previous phone was a Nokia E71 and with its stock set of applications and in spite of its old and rusty Symbian OS, I still have a hard time to even match the basic functionalities on the Android phone even using the most praised apps from the Play Store.

The dialer is crap, there is no decent speed dialer, the focus is on the apps instead of the phone functionality, the homescreen-type-to-search-in-contacts functionality of E71 is probably impossible due to the retarded decision to forget you're using a phone, notifications, even important ones, are hidden, to the point that the ones needing attention can be missed (e.g. entering the PIN/confirmation for Bluetooth pairing must be searched for in the notification area), when looking in the agenda there is no straight one step to edit a contact, you must jump to another application and do the edit there, treating SMS conversations as one to one instant messages works until you want to reply to multiple people at once.

Volume for ringing, SMS notification and the headset are controlled all together, so if during the last conversation you turned down the volume because it was too loud, you can miss a call because our will ring at a lower volume.

And these are only broken things in the basic functionality (for a post 2008 cell phone).

Android phones are smart phones, so more advanced features are required: playing audio and video files, GPS related applications, podcasting support, email handling and web browsing are among the features that can be expected on such a phone.

Only web related functionality and simple media playing are at a reasonable level compared with my old E71, maybe due to Google being web oriented and the new phones having better screens than the old Nokia.

But I am an avid podcast listener, so I've been searching for an application that can match Nokia's Podcasts stock application, and I've come to the conclusion Android users which love podcasts either have to wait for Nokia to develop on Android (which seems unlikely) or find one or two talented developers to create a decent application.

I don't understand how can such an application not have a playlist with the downloaded episodes, not have download all new episodes or mark all/selected as listened. I have found applications that have at least one of these issues and have an average of over 4 out of 5 stars in Google Play. Poor users!

In the light of these issues, I'm having so much difficulty coming up with an excuse for Nokia losing its position as a market leader, but our seems technical superiority is not necessary or enough to dominate the mobile phone market. Sadly, that says a lot about our species, and the words aren't nice.

Friday, 22 March 2013

Finally the XDG fixes are in appdirs

Just a few hours ago my XDG fixes landed in the master branch of ActiveState appdirs.

https://github.com/ActiveState/appdirs/pull/17

They will be part of version 1.3.0, but the maintainers want first to create some tests, since the test frame was just rewritten recently.

Tuesday, 12 March 2013

Herbalife, a detailed analysis

You might remember that a while ago I mentioned I got involved in skepticism to the point I even co-host a podcast, Skeptics in Romania (in Romanian).

Among the subjects we tackle there are claims about various miracle fruits, shady dietary advice, various nonscientific health products, and even scams. We try to inform or listeners about ways to identify themselves such dangerous/fake products and how they can inform themselves about the claims they might encounter, what questions they should ask before considering buying (into) such things.

One sensitive subject is the so called multilevel marketing, especially for people involved in such businesses.

This is a sensitive subject because many of these schemes are actually pyramidal schemes, also known as Ponzi schemes. These are illegal in many countries, since they are, in fact scams designed to lure people with supposed high profits and little work.

One such pyramidal system... well you can judge yourselves (note that the presentation contains many slides, but it's really captivating):

http://www.businessinsider.com/bill-ackmans-herbalife-presentation-2012-12?op=1j

Monday, 4 March 2013

So, I did the responsible thing and fixed appdirs

In my previous post I expressed my frustration at the way a perfectly nice and fine idea, a portable way to get the standard configuration and data directory/files, was broken for Linux and BSD, because the authors of appdirs thought the XDG standard was "subject to some interpretation".

Although I said I decided not to use appdirs, I realised that wouldn't help anyone, so I fixed the code.

During the coding phase I discovered that the authors of appdirs broke the XDG standard even more, this time, ignoring XDG_DATA_DIRS, and talking about XDG_CONFIG_DIRS. When I found this I became convinced the *nix part of the implementation was subject to continuous irony, since the comment in this newly found breakage said "Perhaps should *use* that envvar", referring to XDG_CONFIG_DIRS, but writing later in code:

/etc/xdg/<appname>

Sweet, isn't it?

If you want a fixed version, you can grab it from my repository, on the linux-fixes branch:

https://github.com/eddyp/appdirs/tree/linux-fixes

Tuesday, 19 February 2013

Appdirs from pypi is retarded

The XDG standard says user-specific data files should be written [in] $XDG_DATA_HOME which defaults to $HOME/.local/share.

Appdirs explicitly breaks XDG_DATA_HOME specification and returns a path based on $XDG_CONFIG_HOME, ~/.config/<appname> instead of ~/.local/share/<appname> for user_data_dir. Although the spec is as clear as day, the authors of appdirs say this is 'subject to some interpretation'.

No, it's not, read the damn spec!

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html



The irony is that initially they got it right, but decided to break the standard some two years ago.

Thank you appdirs authors for ignoring a perfectly clear standard just because you *think* 'in practice, Linux apps tend to store their data in ~/.config/<appname>'.


Dear appdirs authors, if some people break the law it doesn't mean the law is broken. And if *you*think* some apps do not conform to a standard, it does mean *at*all* that you should not, either. More than that, if some applications decide on their own they consider some things config data and you'd classify those as 'application data', that's their business, and is not your place to decide to break the standard for everybody. Standards exist for a reason.

 BTW, your software is worthless to me now and I decided NOT to use it because of this idiotic decision of yours.

Friday, 25 January 2013

(Serial) console flooded with kernel messages?

(If you want to ignore the explanations and see how to stop the Linux kernel from flooding the console with low importance messages, go straight to the bottom of the article, is the small bit at end with larger font.)

After connecting to the serial console on my Linksys WRT160NL router I was faced with the problem that the console was flooded with all sorts of messages such as:
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
DROP IN=eth1 OUT= SRC=X.Y.Z.U DST=178.156.183.255 PROTO=UDP SPT=137 DPT=137 LEN=58
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
ACCEPT IN=br0 OUT=eth1 SRC=a.b.c.d DST=69.171.246.16 PROTO=TCP SPT=3651 DPT=443
DROP IN=eth1 OUT= SRC=X.Y.Z.U DST=178.156.183.255 PROTO=UDP SPT=137 DPT=137 LEN=58
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
DROP IN=eth1 OUT= SRC=178.156.183.146 DST=255.255.255.255 PROTO=UDP SPT=17500 DPT=17500 LEN=120
DROP IN=eth1 OUT= SRC=178.156.183.146 DST=178.156.183.255 PROTO=UDP SPT=17500 DPT=17500 LEN=120
DROP IN=eth1 OUT= SRC=178.156.183.146 DST=255.255.255.255 PROTO=UDP SPT=17500 DPT=17500 LEN=120
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
DROP IN=eth1 OUT= SRC=X.Y.Z.W DST=255.255.255.255 PROTO=UDP SPT=58488 DPT=2008 LEN=26
DROP IN=eth1 OUT= SRC=178.156.177.142 DST=255.255.255.255 PROTO=UDP SPT=17500 DPT=17500 LEN=153
DROP IN=eth1 OUT= SRC=178.156.177.142 DST=255.255.255.255 PROTO=UDP SPT=17500 DPT=17500 LEN=153

The serial console was working, but it was impossible to do anything practical in these conditions. I tried looking on the net for 'linux stop console flooding' and similar terms, but didn't get too far, except the fact the problem was the loglevel.

Here is the explanation of what this means (quote from Documentation/kernel-parameters.txt):

        loglevel=       All Kernel Messages with a loglevel smaller than the
                        console loglevel will be printed to the console. It can
                        also be changed with klogd or other programs. The
                        loglevels are defined as follows:

                        0 (KERN_EMERG)          system is unusable
                        1 (KERN_ALERT)          action must be taken immediately
                        2 (KERN_CRIT)           critical conditions
                        3 (KERN_ERR)            error conditions
                        4 (KERN_WARNING)        warning conditions
                        5 (KERN_NOTICE)         normal but significant condition
                        6 (KERN_INFO)           informational
                        7 (KERN_DEBUG)          debug-level messages


This was enough to go through my local git tree of the kernel in the Documentation directory and grep for loglevel. This brought me to this interesting bit from Documentation/sysctl/kernel.txt
==============================================================

printk:

The four values in printk denote: console_loglevel,
default_message_loglevel, minimum_console_loglevel and
default_console_loglevel respectively.

These values influence printk() behavior when printing or
logging error messages. See 'man 2 syslog' for more info on
the different loglevels.

- console_loglevel: messages with a higher priority than
  this will be printed to the console
- default_message_loglevel: messages without an explicit priority
  will be printed with this priority
- minimum_console_loglevel: minimum (highest) value to which
  console_loglevel can be set
- default_console_loglevel: default value for console_loglevel

==============================================================

So I ran 'cat /proc/sys/kernel/printk' and got (I managed to read it through the flood of messages from the firewall):

7       4       1       7
According to the explanations above, that meant that console_loglevel was too, so to fix it I ran:
echo '2 4 1 7' > /proc/sys/kernel/printk
And, behold, the serial console was usable.

Tuesday, 22 January 2013

(Rsnapshot) backup and security - I see problems

In my previous post I was asking for suggestions for backup solutions that would be open/free software, do backups over the network to a local HDD, be cross platform to allow Windows and Linux clients and not be too CPU/memory hungry (on the server).

Several people suggested rsnapshot, BackupPC, areca-backup, and rsync. Thank you for all your suggestions, you have been a tremendous help. I have decided to give rsnapshot a try since it was suggested to me that it would actually do what is supposed to do for Windows clients, too (which was initially my perceived show stopper for rsnapshot).

Still, when getting to the implementation, I was a little disappointed by the very permissive access that needs to be provided on the client machines, since the backup is initiated from the backup server. Even the so called more secure suggested solutions seem way too permissive for my taste, since losing the control over the backup system means basically giving total access to the data from all client machines, which is quite a big problem in my opinion.

The data-transfer mechanism employed by rsnapshot is simply
  1. S ==(connects and reads all data)==> C
  2. S stores data in the final storage area
Am I the only one seeing a problem with this idea? If the server can connect to all your client machines and read all areas as it pleases, even if you restrict it to some directories, the data is already compromised when the backup server is compromised (think .ssh private keys, files with wireless network passwords and so on; I won't say card information - you don't keep credit/debit card information on your computer, or at least not in plain text, do you?).

What I would consider a better alternative would be a server-initiated dialogue which goes a little like this (S is server, C is client, '=' represent connections via ssh):
  1. S ---(requests backup initiation procedure)---> C
  2. S waits for a defined period of time that C connects back to send (already encrypted) data; if it doesn't arrive, it aborts
  3. S <===(sends encrypted data to be backed up)=== C
  4. S <-(signals the completion of data transfer)-- C
  5. S stores the data in the final storage area
This way, the server can allow access from the clients only in designated areas (even a chroot is possible) from designated clients, access can even be provided only after a port knocking procedure and only during the backup time frame (since the server initiates the negotiation, it can expect only then the knocks, but only then), so the server is quite well secured. The connection to the server can even be done through an unprivileged account, it can even be one account per client machine which can be limited to a scponly shell, if you care for that level of security.

On the other hand, the client information is secure since it can be encrypted directly on the client machine and sent only after encryption, the client machine can decide and control what it sends, while the backup server can only store what the client provides. Also, if the server is compromised, the clients' data and system aren't compromised at all, since the data is on the backup machine, but is encrypted with a key only known on the client (and a backup copy of it can be stored somewhere safe).

I am aware this approach can be problematic for permission (user/group preservation), but it doesn't happen if there is a local <-> remote user mapping or simply the numeric IDs are kept.

I am also aware this means smarter clients and might mean the Windows machine might not be able to implement this completely, but a little more security than "here is all my data" can still be achieved, can't it?

What do other people think? Am I insane or paranoid?

I think I can implement this type of protocol in some scripts (at least one for server and one for clients) and use the backup_script feature of rsnapshot to keep this clean and nice within rsnapshot.

What might prove problematic with this approach is that rsync spedup is lost (might be?) because the copy is done to a temporary directory which, I assume, is empty, so tough luck. Another problem seems to be that every time the backup is done, the client has to encrypt each of the files to backup, which seems to be a real performance penalty, especially if the data to be backed up is quite large.

Is there an encryption layer that does this automatically at file level in the same/similar manner that LUKS does for entire block devices? Having the right file names, but with scrambled/encrypted contents seems to be the ideal solution from this PoV.

Thanks for reading and possible suggestions you might point me to.

P.S.: I just thought of this, if there was an encryption layer implemented with fuse which is mounted in some directory on the client machine, the default rsnapshot mechanism could actually work, and this would mitigate the data accessibility issue and the performance issue since that file system could be contained within a chroot and the encryption/scrambling would be done transparently on the client, so no data is plainly accessible. Does anybody know such a FUSE implementation that does on-the-fly file encryption?

P.P.S.: EncFS does exactly what I want with its --reverse option which is exactly designed for this purpose:
Normally EncFS provides a plaintext view of data on demand. Normally it stores enciphered data and displays plaintext data. With --reverse it takes as source plaintext data and produces enciphered data on-demand. This can be useful for creating remote encrypted backups, where you do not wish to keep the local files unencrypted.
Great!

Sunday, 30 December 2012

Looking for a backup application for a small home network

I have been looking at backup solution for the last few days and I am stuck, so I am asking for pointers or suggestions.

Since all backup solutions are appropriate to various needs, here are my requirements for my home network (two laptops backup on a very low powered server with a 3TiB HDD):
  • Free software/open source cross-platform solution - must be able to backup both Linux and Windows clients
  • network backup (to a Debian server, storage on HDD)
  • very low CPU and memory needs on the server side (server is a de-underclocked Linksys NSLU2 running Debian armel)
  • automatic backups with low maintenance cost and easy setup and recovery (setup once, forget about it)
  • easily accessible filesystem based storage
  • clients should be smart enough to detect when they aren't in the home network and not try to backup when away
  • available in Debian
These are the basic requirements, and bonus-points requirements include:
  • Windows clients don't need Cygwin
  • optional encryption (for storage)
  • default sanity checking for stored files (detection/correction of corrupt backed-up files)
  • unduplication (if present, sanity checking is mandatory)
  • logarithmic storage is a plus
  • Web/nice interface for both client and server is a plus
According to the info I found, candidates for these criteria are Amanda and BackupPC. I like the rsnapshot idea of deduplication and incremental backups, but it's not available for Windows. BackupPC seems to be OK-ish, but it sounds too much like a bunch of Perl scripts and Windows support sounds like an after-thought and I dislike the idea of installing Cygwin just to provide some *nix tools.

I discarded Bacula, because the general impression I got from what I read is that it is hard to set up, has its own storage and has heavy needs for both clients and server. It sounds like overkill.

So what do other people recommend for my setup? Is Amanda OK? Did I get the wrong impression regarding BackupPC?

Saturday, 8 December 2012

Consent is needed, but not the point

Russ makes a good point about a nuance of practical jokes that makes them special, the characteristic of involving a third party which is the target of the joke, and how that relates to consent. He is right, consent is an important fact, I acknowledge that. Russ also says at the end of his post that being an asshole doesn't make you responsible for somebody else's decisions, I ackowledge that, too. I even somewhat agree to the position that the employer might fire you on assholery reasons, but in this particular case, I think that's a hypocrite position. If assholery was an issue, it should have been before, too, and I don't think the employer thought of it before this sad even, as long as it meant more money for them. I think this only shows how cynical they are, the cost analysis for them showed them they now might lose more money by not firing, than by keeping them. It's just cynical.

In spite of that, my initial post, just as I wrote, was not about the DJs, the people involved, the assholery, the taste or lack thereof of the joke. That's why I was intentionally leaving out names or specific context. It was about the bigger picture, irrational reactions and how in the face of a tragedy we surrender our thinking capabilities and react in an irrational manner to the least significant things.

I have had quite recent unfortunate events happening to people close to me, and, invariably, I observe this loss of rational faculties in the face of sad events. Even when this kind of disproportionate response is shown for what it is and how it is harmful in itself, people still refuse to give up on being irrational or they do after a long struggle with the facts.

I'll finish my article with a similar question: can we, as a species, go beyond our condition and make a conscious effort to keep calm and think things through before making decisions in the face of tragedy, or are we incapable to do that?

And no, I am not advocating to drop feelings and affection, I find it sad that I have to say that again, but I am almost sure that in spite of it, I will be wrongly understood by somebody.

Faulty logic - confusing correlation with causation

I want to start this post by saying two things:
  1. It is sad when a good person decides to commit suicide
  2. It is even sadder anyone writing on a subject like this MUST add this kind of disclaimers in the hope the message of the writing isn't distorted because we are unable to listen to each other without suspecting/blaming the other of pure evilness/lack of compassion.
 Imagine you are working in an office with other colleagues and one of them makes a print screen of your desktop screen and then displays it full-screen on your computer. You struggle a little and get frustrated when nothing works, the colleagues laugh at your expense. Pretty childish, but no harm, right? You laugh it off.

 Imagine a similar scenario, but your shoelaces are tied to the desk without your notice, and the colleagues tied your laces so you can't stand, so the risk of injury is null. You stumble a little when you want to leave the desk. Again, childish, funny, but no harm, right? Again, you laugh it off.

 Imagine even a scenario where you are the target of a prank that doesn't injure you physically, but it happens in front of an audience of 100 people. You might feel ashamed, embarrassed, depending on the prank. But that would go away with time, with your laughs or by leaving that audience, right?

 So now imagine you are just a person that unknowingly contributed to the success of a harmless prank in which somebody was duped into thinking they were talking to a very public figure about some unimportant and inconsequential stuff related to their job. You'd brush it off, wouldn't you? Most likely, you'd probably laugh at the prank and you wouldn't think the pranksters should be prosecuted or fired. Even if the famous public figure would be upset, taking into account the fact that the things discussed were inconsequential, you wouldn't worry about it. I wouldn't worry even if that famous person was my direct boss and I was the one talking about my boss.

 At least, that's how I am thinking, but for some reason, many people don't think this way. And yes, I am talking about the recent sad news about the apparent suicide of a nurse who was involved in the care of the person called Kate Middleton.

 I don't want to talk about names, or man-made titles, man-made concepts, or how some people forget that even the most influential people in the world are still a member of this same species that all of us are. I don't even want to talk about this particular sad situation, I just want to talk about the totally irrational reaction many people had to it.


 Everybody knows that jokes are a matter of taste. What I might consider funny, some people would take offence at, but, generally speaking, there's an area of jokes that even kids would consider funny. Also, if we are honest to ourselves, a joke is not funnier or less funnier if from the total of people in the room instead of 2 people not liking it, 5 people don't. Not even if some of them are so offended by the joke they leave the room. The joke is equally funny or in poor taste with 2 or with 100 people in the room.

 And there's the issue of confusing correlation with causation. If I tell somebody some good news about my aunt and the next day that somebody happens to had bought a car, it doesn't mean my good news made that person decide they want to buy a car. It could be, but it's not necessary, it could be a coincidence.

 The same happens in the sad case of the nurse. She decided to take her life, as far as it seems. But that's the extent to which we know anything about the situation. We don't know if the suicide had anything to do with the prank or not. Just the fact that it happened the next day doesn't mean AT ALL the prank call is the cause of the suicide. It doesn't even mean that is "the straw that broke the camel's back", it might be totally unrelated. Or it might not. Taking into account the inconsequential and harmless nature of the call, it seems even less likely. Yet, I might be mistaken.

 What I am sure of now is that jumping to the conclusion that the prank call had anything to do with the death, is wrong, as it is jumping to the opposing conclusion. I am also sure that in the absence of other information, the latter, the lack of connection, is more likely, because we know that such drastic sad decisions are not generally caused by trivial stuff.

 Time proximity doesn't prove causation. Geographical proximity doesn't either. There needs to be a lot more into it than simple temporal sequence.



 Which gets me to the second part of irrational reactions: terminating the show and twitter accounts of the two pranksters. What the hell? Talk about hypersensitivity and paranoid reactions! Are we this blind and willing to blame the least insignificant thing for the gravest consequences that we forget how we all make decisions and how to use our brains, as soon as some tragedy happens?




 Imagine some person who thinks the 21st of December 2012 will bring the end of the earth. Imagine that person taking as a serious declaration the obvious joke from the Australian prime-minister Julia Gillard, and would end their lives to avoid the mayhem, panic and violence they think would follow the 21st of December. I wonder, would as many people blame Julia Gillard for the suicide? I doubt it. And the irony is that for such an hypothetical case, there would be a stronger case for causation than what we now know about the previous case.


 I still wonder,  when will we learn to think a little more rationally than the people walking the Earth 100.000 years ago?

Saturday, 24 November 2012

Singing your way to Parliament

Here is a "customized" version of a political ad that I made based on the real one of a guy running in the area where I live right now. I made it as a joke, I don't endorse the guy at all. In fact, I think that I would advise anyone having this guy on the ballot, to vote whomever else.



The candidate is a singer part of a band which had it's heyday around the beginning of the previous decade. His slogan is "Facts not words", but I thought "Rhymes, not words" is more appropriate.

There are two other jokes in here, I hope my Romanian readers will appreciate them.

Tuesday, 16 October 2012

Zenyth Pharmaceuticals cannot face(book) critics, so they cleanse them

A few days ago I wrote an article about the lawsuit the producers of ColonHelp are trying against Wordpress in the attempt to silence a blogger who wrote some unfavourable and science-based articles on his blog.

Meanwhile Petter Reinholdtsen (who seems to be a fellow skeptic, hi!) sent further this information via his blog, but on another front, I found out the German skeptics tried to contact Zenyth Phamaceuticals on Facebook and asked them why did they use lawyers for threats against critics, instead of using words and thorough scientific studies to talk to the critics.


The people at Zenyth Pharmaceuticals probably wanted to show they do not only use lawyers, but they can be very proficient at using the 'Delete' function of Facebook, so they did just that, it seems.

This really motivates me to go ahead and translate the article Zenyth's money didn't translate, the one that shows their entire case is baseless.

Monday, 15 October 2012

HOWTO: sudo + cowbuilder (+git-buildpackage)

In case you tried to use git-buildpackage and wanted to use cowbuilder as a builder, you might have ran into the error

sudo: sorry, you are not allowed to preserve the environment

This is due to a change in sudo default configuration in version 1.7.4p4-2 (I know, is true since 2010) which doesn't allow the execution of commands via sudo using the parameter '-E' which means 'setenv'.

The news item even explicitly states pbuilder can be affected by this because it wants to port over to the pbuilder environment the HOME environment variable and suggests using

Defaults env_keep += HOME

But adding such a line to your /etc/sudoers.d/01_pbuilders file (/etc/sudoers is recommended to be touched only by the package) will do the  same for all commands and users ran via sudo, which is, according to my preferences, too permissive.

The irony is that running git-buildpackage --git-pbuilder  will invoke sudo -E cowbuilder so the env_keep suggested fix will not work because for -E to be allowed, setenv needs to be set in sudoers. This would defeat the purpose of env_reset, if done for all commands, but we can do a better job if we allow this kind of change only for the cowbuilder and pbuilder commands. You do have different commands that are allowed explicitly stated, don't you?

On my system I have made a group especially for people allowed to do packaging work, the group is called 'pack'. The only account in that group is my own.

Also, I have defined a command alias named PBUILDERS which looks something like this:

Cmnd_Alias PBUILDERS = /usr/sbin/pbuilder, /usr/sbin/cowbuilder

Running PBUILDERS is already restricted to the pack group. Here is an example that requires password on run:

%pack ALL=PBUILDERS

So all that needs to be done is to allow setenv for the PBUILDERS commands. Reading through the sudoers manpage and after some trial and error (use visudo for editting sudoers files - visudo -f /etc/sudoers.d/01_pbuilders) I found out that the symbols that distinguish between commands, users and groups in a 'Defaults' line needs to be right next to the 'Defaults' word. For command the sign is an exclamation sign '!' (for user lists it's ':') so since we want to link the exception to the command, not the user list, we'll use 'Defaults!':

Defaults! PBUILDERS setenv

Assuming you also have a PBUILDERS commands alias, this is what you need to be able to use git-buildpackage in conjunction with cowbuilder and sudo.

If there is a non-intrusive way to prevent sudo to use -E when invoking cowbuilder, please add your comment, I would be interested to know it.

Friday, 12 October 2012

A shitstorm is comming

It has been brought to my attention that a company selling some so-called colon cleansing product wanted to threat with a law suit a Romanian skeptical blogger because he wrote some articles showing that any such products (the one produced by the said company is the most known/popular in Romania) are pure quackery and there is no scientific basis for the claim they make in order to promote their products.

In his articles he also explained how, in fact, the mucoid plaque, the thing that supposedly proves the efficiency of the product, it is a result of taking the product due to its ingredients, and how no such mucoid plaque was ever observed in any colonoscopy, colon surgery or any other situation where you'd expect it to be seen. He also quoted specialists and lots of other scientific references, showing an honest approach to the issue.

As a response to the initial take-down message from the company doing business with people's crap, the blogger said would like to see scientific proof for the claims made for the product, and when that was to happen, he would take down the articles and publish a correction.

The company decided that the best way to continue this was to try to make a legal threat and ask 100.000 euros (one hundred thousands Euros) as damage in a country where, according to the latest data from the National Statistics Institute, the total average monthly personal income is about 180 Euros.

The blogger, as a reply, decided the threat should be made public and wrote another article which probably made the company very unhappy, because they decided to sue Wordpress so they would take down the blog.

And that's exactly what they did, they sued Wordpress, and sent some documents to Wordpress who sent them to the blogger. Among the documents there were 4 pdf files containing each an original article (in Romanian) from the blog and only 3 pdf containg English translation for only 3 of them. The one missing was the one where the blogger himself showed there wasn't any legal basis for the threats they made initially against him.

Here are the translations (ironically, made on the company's own expense):

Initial article entitled "ColonHelp doesn't help the colon. But it empties your wallet!" (original here)
Initial Article.en



The second article entitled "Again about ColonHelp and intestinal cleansers" (original here)
Follow Up.en



** Missing translation of the first reply to threats (original Romanian text here)



The second article about the threats entitled "People who clean the colon have filled the fan with shit" (original here)
Threats 2


The Romanian blogger explains himself more of the details on this issue in his latest article on his blog.

The company is called Zenyth Pharmaceuticals and Wordpress will probably lose the lawsuit by not presenting themselves in any way in the Romanian courts, but I think some Streisand effect would really help the asses of this company to get them kicked in their rightful place, at the top of the hall of shame.

The product name is called ColonHelp.

Please spread this information as wide as possible.
Do NOT link to the company's site (it would raise its search engine rank), but link to the blogger' article or the translations.


If any Romanian speaker cares to translate the untranslated article and publish it somewhere on the web, I would be more than glad to update this article and add a link to that translation.