Last Thursday, I was at a conference called
Listening to the Social Entrepreneur. Here are some short notes about the plenary session, which were written at the time, along with thoughts on the workshops that I’ve just written up.
HCT Group - credit crunch opportunity - business with ethics - transport - dislike 3rd sector term - difference between social enterprise and charity - optimism.
Haley House - ex-soup kitchen staffed by ex-homeless, bakery, bank donated equipment, financial picture - catering grew 36% cafe grew 21% september, cooking classes; recipe for success: collaborate with experienced partner, secure enough capital or equivalent, align venture with mission; plan for sustainability; future…
Roskilde university - relevance of academic research - why references for things I know - hard to have your feelings discussed. (meeting last Monday?) - don’t care what it’s called - too much jargon - several ways of learning, conceptual doesn’t seem useful but will later. CICs. Four flags of SEs - eship, er, e, econ.
Bikeworks - practitioner and academic. Formation, setup, establishment, sustain. SE changes; viewpoint: academic, researchers, help us. Useless website.
Then came three workshops of varying usefulness:
Procurement Versus Marketplace was an interesting idea and reminded me why I avoided public-sector projects for years: I’m better at negotiated than at rules-based selling. I also was told (with a straight face) by a development trust worker that cooperatives are simply profit-sharing schemes, which was very disappointing.
Social verses Business Goals seemed pretty ill-conceived. The reason why many people work in social enterprises is because we don’t believe we should choose between them. It’s an integrated, multi-faceted approach.
Born or Made? was an interesting examination of the people powering social enterprises. Food for thought, but I’m not sure it really produced much. But I’m not that sure whether any of the workshops had much of a productive purpose.
The final plenary session was confusing. I was sat further back, the sound system was intermittent and echoy and the talks seemed truncated and still, but maybe I was just tired. A lot of people had left by this point. I stayed on for the networking reception and met a few interesting people, but left earlyish to meet another
TTLLP member on the light railway.
The venue was OK (I think the main hall problems were more sound system and operation than the hall itself) and coffee, lunch and reception were well-catered.
In conclusion, it was an interesting conference, but I don’t feel that we got much out of it, apart from some thoughts from a workshop session. I suspect it was more useful for the researchers than for the entrepreneurs. There weren’t many opportunities for professional development or sales or even putting things into consultations or . I’m not sure I’d spend best part of two days work (attending plus travel plus costs) on another similar event.
One thing that concerns me about using any online service is the security. When that service is a virtual server running in another country the risks are greater than average.
I’m currently investigating the Amazon EC2 service for some clients, and naturally I’m concerned about the security. Firstly
they appear to have implemented a good range of Xen based security mechanisms, their documentation is worth reading by anyone who plans to run a Xen server for multiple users [1]. I think it would be a good thing if other providers would follow their example in documenting the ways that they protect their customers.
Next they seem to have done a good job at securing the access to the service. You use public key encryption for all requests to the service and they generate the keypair. While later in this article I identify some areas that could be improved, I want to make it known that overall I think that EC2 is a good service and it seems generally better than average in every way. But it’s a high profile service which deserves a good deal of scrutiny and I’ve found some things that need to be improved.
The first problem is when it comes to downloading anything of importance (kernel modules for use in a machine image, utility programs for managing AMIs, etc). All downloads are done via http (not https) and the files are not signed in any way. This is an obvious risk that anyone who controls a router could compromise EC2 instances by causing people to download hostile versions of the tools. The solution to this is to use https for the downloads AND to use GPG to sign the files, https is the most user-friendly way of authenticating the files (although it could be argued that anyone who lacks the skill needed to use GPG will never run a secure server anyway) and GPG allows end to end encryption and would allow me to verify files that a client is using if the signature was downloaded at the same time.
More likely problems start when it comes to the machine images that they provide. They have images of Fedora Core 4, Fedora Core 6, and Fedora 8 available.
Fedora releases are maintained until one month after the release of two subsequent versions [6], so Fedora 8 will end support one month after the release of Fedora 10 (which will be quite soon) and Fedora Core 6 and Fedora Core 4 have been out of support for a long time. I expect that someone who wanted to 0wn some servers that are well connected could get a list of exploits that work on FC4 or FC6 and try them out on machines running on EC2. While it is theoretically possible for Amazon staff to patch the FC4 images for all security holes that are discovered, it would be a lot of work, and it wouldn’t apply to all the repositories of FC4 software. So making FC4 usable as a secure base for an online service really isn’t a viable option.
Amazon’s page on “Tips for Securing Your EC2 Instance” [3] mostly covers setting up ssh, I wonder whether anyone who needs advice on setting up ssh can ever hope to run a secure server on the net. It does have some useful information on managing the EC2 firewall that will be of general interest.
One of the services that Amazon offers is to have “shared images” where any Amazon customer can share an image with the world.
Amazon has a document about AMI security issues [4], but it seems to only be useful against clueless security mistakes by the person who creates an image not malice. If a hostile party creates a machine image you can expect that you won’t discover the problem by looking for open ports and checking for strange processes. The Amazon web page says “you should treat shared AMIs as you would any foreign code that you might consider deploying in your own data center and perform the appropriate due diligence“, the difference of course is that most foreign code that you might consider deploying comes from companies and is shipped in shrink-wrap packaging. I don’t count the high quality free software available in a typical Linux distribution in the same category as this “foreign code”.
While some companies have accidentally shipped viruses on installation media in the past it has been quite rare. But I expect hostile AMIs on EC2 to be considerably more common. Amazon recommends that people know the source of the AMIs that they use. Of course there is a simple way of encouraging this, Amazon could refrain from providing a global directory of AMIs without descriptions (the output of “ec2dim -x all“) and instead force customers to subscribe to channels containing AMIs that have not been approved by Amazon staff (the images that purport to be from Oracle and Red Hat could easily have their sources verified and be listed as trusted images if they are what they appear to be).
There seems to be no way of properly tracking the identity of the person who created a machine image within the Amazon service. The ec2dim command only gives an ID number for the creator (and there seems to be no API tool to get information on a user based on their ID). The web interface gives a name and an Amazon account name.
The next issue is that of the kernel.
Amazon notes that they include “vmsplice root exploit patch” in the 2.6.18 kernel image that they supply [2], however there have been a number of other Linux kernel security problems found since then and plenty of security issues for 2.6.18 were patched before the vmsplice bug was discovered - were they patched as well? The file date stamp on the kernel image and modules files of 20th Feb 2008 indicates that there are a few kernel security issues which are not patched in the Amazon kernel.
To fix this the obvious solution is to use a modern distribution image. Of course without knowing what other patches they include (they mention a patch for better network performance) this is going to be difficult. It seems that we need some distribution packages of kernels designed for EC2, they would incorporate the Amazon patches and the Amazon configuration as well as all the latest security updates. I’ve started looking at the Amazon EC2 kernel image to see what I should incorporate from it to make a Debian kernel image. It would be good if we could get such a package included in an update to Debian/Lenny. Also
Red Hat is partnering with Amazon to offer RHEL on EC2 [5], I’m sure that they provide good kernels as part of that service - but as the costs for RHEL on EC2 more than double the cost of the cheapest EC2 instance I expect that only the customers that need the the larger instances all the time will use it. The source for the RHEL kernels will of course be good for CentOS (binaries produced from such sources may be in CentOS already, I haven’t checked).
This is not an exhaustive list of security issues related to EC2, I may end up writing a series of posts about this.
Share This
Version 1.2 of reportbug-ng now shows the tags of a bug if available. This was long overdue. Now you can for example, quickly search your bugs for the ones with the moreinfo-tag set and sort the resulting list by the date of the last action. This should give you a quick overview of bugs which may need some action (eg. another reminder to the submitter) or can potentially be safely closed.
In the next step I’ll improve the filter of rng and add a context menu which will allow to manipulate the tags of one or more bugreports and send all the changes in a single mail to control@bugs.debian.org.
A few years into this running hobby, I realized that my times were getting
better. But I had no feel for by how much, or whether that was a constant
rate of improvement etc pp. Long story short, I started to plot some of the data. What
seemed natural was to record the date, the distance in miles as well as in a
qualitative variable, and finally the average pace. Additionally, I played
with groupings into just three categories 'short', 'mid' and 'long'.
This leads to a natural 'one-factor' model of pace as a function of race date
grouped by race distance. And given how easy it is to do conditional plots in
R,
I quickly arrived at something that
already resembled the following chart:
At first, some of the groups had too few data points to actually reliably
construct regression lines, let alone non-parametric smoothers. But over
time more and more data points were added as I kept running races.
Including for example the somewhat disappointing result from
last
year's Chicago marathon in record heat that resulted in the outlier in
the last panel. It actually made the smooth fit turn upwards! Luckily, the
subsequent times in
New York last fall,
London in April,
and of course in
Berlin last month
helped to dampen the effect of the one outlier, resulting in a more normal straight line for marathon
performance that is comparable to the other four race lengths.
All in all I am now quite happy with the chart. The combination of the
non-parametric loess smoother and the
robust linear regression (using
lrm
from the
MASS package
for
R)
shows that most groups exhibit very little non-linearity as both regression curves are very close to each other.
The curvature in the '10m' group is probably mostly a small-sample effect. And I am obviously happy with the
fact that three of the five panels show their respective last race as a PR :)
The
R script containing the data and code
is available here
but requires some familiarity with the
lattice package for
R (as the
lattice book
would provide).
In a recent blog post,
Kai
complained about various existing tools for marking up email in HTML.
He also asked for pointers to other tools. Since he didn't specify good tools :-), I took the opportunity to promote my
work in progress plugin for
ikiwiki
to do that very thing.
When asked about demo sites, I realized that my blog doesn't actually
use threaded comments, yet, so made a poor demo.
Follow the
link and you will find one of
the mailboxes from the
distribution,
mostly a few posts from one of the debian lists.
The basic idea is to use the Email::Thread perl module to get a forest
of thread trees, and then walk those generating output.
I think it would be fairly easy to make a some kind of
mutt-like
index using the
essentially same tree walking code. Not that I'm volunteering
immediately mind you, I have to replys to comments on my blog working
(which is the main place I use this plugin right now).
Anand Kumria
wrote:
If IBM were to go bankrupt, would the government step in? Unlikely. Investors would lose (money), staff — another word for investors — would lose (jobs), but customers would win (their computers would keep working). Some customers would win more than others (especially those who had the equipment on lease); if no one is collecting, why pay?
I’m wondering here where Anand got the idea that once a company went bankrupt, that you don’t need to pay to that company anymore. When a company goes bankrupt, at least in Germany the following happens: A trustee/liquidator is selected. This liquidator is then collecting the information who owes money to the company and who still needs to get (how much) money from it. The liquidator also has to check the option of selling company assets (which might include the contracts of customers that still have to pay) to fulfill the debts of the bankrupt company. After he turned all assets into money, the money is distributed among those who still have to get money from the bankrupt company.
Anyway, regarding his main argument that the (average) customer of a company (bank in this case) should never have to pay for the failed speculations of that company, I somehow have to agree with him. Someone putting money into a regular bank account or papers with fixed interest rate should never lose his money. But there are also customers buying bank shares with a chance of higher revenue than with fixed interest rate papers. These should suffer from failure of the bank management, as they more or less explicitly wanted to be tied to the success (or failure) of the bank.
However, this is mostly irrelevant, since the failure of so many “investment banks” has side affects that might cost the average inhabitant of the affected countries even more than the discussed rescue plans. One of these effects is that the banks are now much more conservative regarding lease and mortgage plans, effectively leaving many home owners with no option to fulfill previous obligations (remaining debt after a previous mortgage expired can’t be refinanced by a new mortgage), causing them to have to sell their homes to pay the first mortgage. This is in some way stupid because this causes people who were perfectly paying their mortgage rates to loose their house, while the bank which would be giving them a new mortgage could get a new and good customer, improving their income. On the other hand, if the other side effects of the current crisis cause those “good” mortgage customers to loose their jobs, they might turn into bad customers who are unable to pay their rates. All in all, this is a spiral that could cause the whole economy to break down (a small example: The bank is not giving out mortgages, so no one will build new houses so the builders loose their jobs so they don’t pay their mortgage rates anymore,…. - over simplified, but still shows what I mean). Unless the spiral is terminated in time, before too drastic things happen.
All in all, I do understand why the politicians try to rescue those banks (or at least the customers of those banks), though I think that in an economy with slightly higher regulation, there wouldn’t be the need for such a rescue plan. I know there are some german banks affected by the crisis as well (among them Hypo Real Estate and others), but the average private customer of such banks shouldn’t loose money due to the regulations we have in place.
In general, there should be some security fund which makes sure that private customers never loose money put into regular bank accounts or fixed interest papers, vice-versa, banks should calculate mortgages so that they can be pretty sure their customers are actually able to pay off their rates - it doesn’t make sense if someone starts off having to pay 500$/month for their mortgage and has to pay over 1000$ a few years (as in 2-3 years) later, because the bank raised the interest that much. I have no problem with people loosing money from shares of banks or other companies directly or indirectly through investment funds.
ELF has two related concepts for managing symbols in your programs.
The first concept is the symbol binding. Global binding
means the symbol is visible outside the file being built; local
binding is the opposite and keeps the symbol local only
(
static) and weak is like global, but suggests that
the symbol can be overridden.
$ cat syms.c
static int local(void)
int global(void)
int __attribute__((weak)) weak(void)
$ gcc -o syms -c syms.c
$ readelf --syms ./syms
Symbol table '.symtab' contains 10 entries:
Num: Value Size Type Bind Vis Ndx Name
...
5: 00000000 8 FUNC LOCAL DEFAULT 1 local
8: 00000008 8 FUNC GLOBAL DEFAULT 1 global
9: 00000010 8 FUNC WEAK DEFAULT 1 weak
...
This is all well and good, but starts breaking down when you want
to load many different modules and keep strict API's (such as, say,
dynamic libraries!).
Consider that for two files to share a common function, the
function must end up with a global visibility.
$ cat file1.c
void common_but_not_part_of_api(void)
$ cat file2.c
extern void common_but_not_part_of_api(void);
void api_function(void)
common_but_not_part_of_api();
$ gcc -shared -fPIC -o library file1.c file2.c
$ readelf --syms ./library
Symbol table '.symtab' contains 60 entries:
Num: Value Size Type Bind Vis Ndx Name
...
53: 00000424 29 FUNC GLOBAL DEFAULT 11 api_function
55: 0000041c 5 FUNC GLOBAL DEFAULT 11 common_but_not_part_of_api
...
In the example above, both the function we want exported
(
api_function) and the function we don't wish exported
(
common_but_not_part_of_api) end up with exactly the same
attributes. Binding attributes are useful for the linker putting
together object files; but aren't a complete solution.
To combat this, ELF provides for visibility attributes.
Symbols can be default, protected, hidden or
internal. Using these attributes, we can flag extra
information for the dynamic loader so it can know which symbols are
for public consumption, and which are for internal use only.
The most logical way to use this is to make all symbols by default
hidden with
-fvisibility=hidden and then "punch holes
in the wall" for those symbols you want visible.
$ cat file1.c
void common_but_not_part_of_api(void)
$ cat file2.c
extern void common_but_not_part_of_api(void);
void __attribute__((visibility("default"))) api_function(void)
common_but_not_part_of_api();
$ gcc -fvisibility=hidden -shared -fPIC -o library file1.c file2.c
$ readelf --syms ./library
Symbol table '.symtab' contains 60 entries:
Num: Value Size Type Bind Vis Ndx Name
48: 000003cc 5 FUNC LOCAL HIDDEN 11 common_but_not_part_of_api
54: 000003d4 29 FUNC GLOBAL DEFAULT 11 api_function
Now the dynamic loader has enough information to distinguish
between the two, and can stop any external access to
common_but_not_part_of_api easily.
This extra information also has potential for performance
improvements. Any time a symbol may be overridden, the compiler must
generate a program lookup table (PLT) entry for the function so
that the dynamic loader can re-direct the function call. The PLT is a
trampoline which gets the correct address of the function being called
(from the global offset table, GOT) and bounces the function
call to the right place. An example should illustrate:
In the first example, there was not enough information to tell if
the function would ever be able to be overridden, hence a PLT entry
had to be created and the function called through it (disassemble it
to see the details!). With correct symbol visibility attributes,
there is enough information to know that
common_but_not_part_of_api is never to be overridden, hence
the PLT (and the associated costs of trampolining) can be avoided.
The internal attribute is even stricter; it says that this
function will never be called from outside this module (for
example, we might pass the address of
common_but_not_part_of_api to anyone). This can lead to even
better code, because on many architectures transitioning to another
module might involve flipping global pointer registers or other
similarly expensive operations.
So that's how symbol binding and visibility attributes can work
together to get you the best performance possible from your
program!
You probably noticed by now, that Debian GNU/Linux 5.0 aka
Lenny
hasn't been released in September. Well, that's a shame, but very easy to
explain: Too many
release critical
bugs.
Well, it's pretty hard to estimate, how fast RC bugs will be fixed, and
apparently our release team was a bit too optimistic :(
The big question is: What can you do, to help release
Lenny
at
least in this quarter? That's pretty easy: Fix rc-bugs, take care, that
the fixed packages are migrated to
Lenny
, do upgrade tests, document
problems in the release-notes. Pretty simple, isn't it?
For users
Even as a
simple user
(aren't we all just users?) you may help
getting
Lenny
released. Some things you can do:
- If you are running stable (aka
Etch
), you could consider
upgrading to Lenny
and see, if everything works fine. Currently
there are no detailed release notes documenting the procedure, so you
best way to test upgrades are to:
- Make backups
- Change your /etc/apt/sources.list
- Run aptitude update to get information about new
packages
- Run aptitude install dpkg aptitude apt script to install the
newest package management
- Run script aptitude full-upgrade
- Exit the environment of the script command, by typing
exit
If something goes wrong / something unexpected happens, please report it.
If you already know a specific package, report a bug against that
package. If you don't know, please report a bug describing the problem you experienced to
the upgrade-reports package. If your problem is something,
which can't be fixed properly, but should be documented (e.g. hardware
support regressions, packages no longer available) please report a bug against
the release-notes package (Bonus points if you not only
report the bug, but also supply a paragraph to be added to the release
notes).
The command script will log the entire output of the command in
the file typescript. Should something go wrong during the
upgrade, please send this file along with your bug report.
Update: If you upgraded succesfully, you should report that, too.
There's a template for
upgrade reports, which you can use.
- Speaking of the release notes: You can take a look at the bugs
reported against the release notes and see if
you can help there, e.g. by writing a paragraph describing a problem.
- Install the package devscripts (you'll need
the version provided by backports.org, and run the script
rc-alert --include-dists TU --include-dist-op and. You'll get a list of release
critical bugs open for one of the packages you have installed. Guessing
that you have them installed, because you are using them and are
interested in them, you should have a very high interest to get these bugs
fixed :)
You can try to help, by trying to reproduce them and
reporting that to the bug report. There are even some easy bugs, where
the maintainer hasn't found the time to fix it, yet. Bug 497290 for example didn't
need deep technical skills. It just needed someone with some time to
collect the needed data for the copyright file.
- If you speak a language other than English, you might consider
joining the translation efforts. While it is to late to translate the
debian-installer or the installation guide to a new language for
Lenny
(perhaps for the next release then?), you could start
translating the release notes to a not yet supported language. If you
are willing to do so (which can be quite time consuming, especially in
the final phase), please contact either your localization team or
the debian doc mailing
list if there's no local mailing list.
See? Even as a
simple user
without deeper technical knowledge
you can help us getting
Lenny
in shape to be released. If you have
technical knowledge: Very good! You might want to read the next
section, too, and see what applies to you, there :)
For maintainers
It basically boils down to two things: If your packages have RC bugs
open in
Lenny
fix them and take care, that the fix will propagate to
Lenny
. If your packages don't have RC bugs open, fix someone else's
RC bug. Surely you don't think, the release team will fix the remaining rc
bugs, do you? And surely you understand, that your shiny rc bug free
packages are kind of useless, if they aren't released?
To search for bugs to be fixed, take a look at
the
unofficial rc bugs thingy. The URL lists RC bugs open in both
Sid
and
Lenny
. Obviously they should be fixed ASAP. If no
one takes care about these packages, they might be removed from
Lenny
(if possible).
Again: Try to reproduce the bug, try fix it, upload an NMU (or send
your patch to the bug report and search for an sponsor). You'll notice,
that some of these bugs already have a patch. In that case, your job would
be to test the patch, report that to the bug report and offer to sponsor an
NMU.
Another interesting list is
the
list of rc bugs open only in Lenny
. These bugs have been fixed,
but the fix hasn't propagated to
Lenny
, yet. Normally, the release
team will grant freeze exceptions for these packages if possible.
However, if the changes to the fixed version are quite grave or the package
in
Sid
depends on a newer package than in
Lenny
that's not possible. In these cases look out for packages
marked as
need tpu upload
or similar.
Oh, and if you could refrain from upload new upstream versions of packages to
Sid
, you would make all our lives easier. Some reasons:
- New packages won't reach
Lenny
anyway.
- Upload new packages to
Sid
makes it harder to get a fix into
Lenny
should a new bug be found.
- Uploading a new package makes it harder for other packages depending
on your package to be migrated to
Lenny
.
- You are wasting the buildd's time.
And of course you should spend your time fixing rc bugs anyway ;)
Update: Rhonda pointed out, that running
rc-alert -d TU -o
and will limit the output to bugs open in both
Sid
and
Lenny
, which is the more interesting list of bugs.
It’s really funny to see how popular things can get, and then totally disappear. Some time ago, there was a TV show on the french TV called “Un an de +”, that talked about what was in the news one year before. It was really interesting to see how quickly everybody can forget stuff that looks so important now.
For example, who remembers Second Life? Apparently, it has been on the decline for some time already, according to Google Trends:
Will Facebook be the next Second Life?
I just got back from the
OpEd project/workshop. In short, it was worth every penny and if you are interested in writing an OpEp and riding the public debate bandwagon, this is the perfect place to start. Why? Well, first because the world of punditry and debate needs more diversity and women and this project is fundamentally geared toward getting more women into the system and in a no nonsense, accessible, inspiring, and yet utterly pragmatic fashion.
First, if you don’t know the stats concerning women, they are depressingly dismal. For example, 9 out of 10 submissions are from male writers and 88% of published pieces are from male authors (and this is matched by all sorts of other disturbing figures about the lack of women non-fiction writers, TV producers etc). In the OpEd field, the main problem, in short, is that women are not even trying.
Today’s full-day workshop was enlivening and engaging.
Catherine Orenstein, the founder and dynamic leader of the project, dusts away a lot of the mystery of this writing genre and equips participants with some basic skills and tactics to get you started (then, in my opinion, it takes a fair bit of work and persistence to master, just like any type of writing but it is not rocket science either).
What I like most about the project is its utter pragmatism. Cathy knows that once there are enough women in the system, the project can close shop, for it will be other women who will take over the reigns and inspire other women to write them (and informally mentor them as well). It is well known, for example, that once there is a critical mass of women, let’s say in the work place, then these women are the point people for recruitment so that the company does not need to actively recruit women.
I have heard this argument before and have had a number of personal experiences that confirmed this fact. Last year, for example, a student from my department was organizing a conference and he could not, for the life of him, find any female speakers or discussants, despite asking a number of them who declined because of other commitments. He had ran out of options, that is, until he talked to me. In less than a minute, I rattled off like 5-7 other possible choices and within a day, we had 2 on board. It is clear that women know other women (and many are friends) so the best person to go to to tap into are other women.
In terms of the actual writing of an OpEd, I am not sure I will be writing one anytime soon in so far as I need to really pump out a few more academic articles as the future of my jobs depends on them. But I may write a draft version of one that I will hammer into finer shape if a timely news event arises. Otherwise, I look forward to spending more time on this genre, especially once my book is done and know that if I am going to stay in academia, I will for sure make space for this type of thinking and writing.
Finally if you are interested in attending one of the
public, women-only seminars and you know me, let them know you learned about the project through me, and you will get discount.
I received
some
feedback on
my previous
BeID post, where I explained how to log in to a remote system by use
of your digital ID card.
Philip and Guy both claim it possible or likely that the crypto keys
on eID cards are stored on a system of the government somewhere and that
you therefore should not be using them.
I find this to be jumping the gun a little. Security is always a
trade-off; indeed, if you want to hide stuff from the government, then
using eID-based authentication might not be a very good idea. However,
there are other cases where eID-based authentication really
is
the correct option; and it is nice to know that this kind of thing is
possible. Security always is a trade-off; and if you make an informed
choice, there's nothing wrong about giving someone else access to your
server.
The fun bit is that Philip actually advocates
carrying
a clear-text printout of a list of still-valid passwords. Now
that, I feel, is unacceptable, security-wise. Personally, I'd
rather use a smartcard that only some secret government agency
might be keeping copies of rather than a list that any random
thief might make use of. The question really boils down to this, I
think: how likely do you think it is that someone else will be able to
get at your password by guessing or stealing it?
- Using a password that's related to your person or someone near
you, or is based on a dictionary: rather likely. There are scripts out
there that will guess these passwords. Don't use them.
- Using a printout of a list of one-time passwords: somewhat less
likely (they can't be guessed by script), but still not very hard
(wallets get stolen by the hundreds every day, and it usually takes a
while before one notices)
- Using smartcards with keys generated by someone else: somewhat
unlikely (there may be a few people who know my private key,
but one can't be sure of that; and, color me naive, but I tend to trust
the government to abide by its own laws—for the most
part—laws that prevent this kind of behavior)
- Using strong password: rather unlikely, provided you take care of
them.
What I mean by that last bit is that you should always generate your
passwords with a tool that generates fully-random passwords ('pwgen -s',
for example), and never write them down in cleartext anywhere. That of
course makes it slightly hardish to memorize them; what I do is to store
the password encrypted to my GPG key on my laptop, and I memorize the
password by changing it on a remote server that I need to access fairly
often (Debian's systems will do), but leaving my GPG passphrase and
laptop password as is for the time being. Every time I need to log in to
the remote server, I first try to remember the passphrase. If I can't
remember it, I look it up in the encrypted file (again taking care not
to store the file on disk). Once I start being able to log in to the
remote server
without having to look it up in the file, I
change all my other passwords. This process usually takes a few
weeks. Then, the
only way someone can get my password is either
by coercing me or by killing me and disecting my brain. And then
still.
Unfortunately, in the real world, I realize that many people do not
wish to go through all this trouble just to get a secure login, and
instead just choose a weak password. I guess that's why I think the next
best thing might be slightly better than using strong passwords...
They say that there's very little difference between love and hate. A good
example of this is the
Linux Hater's Blog. It's
written by someone who obviously has a lot of experience with Linux and
Open Source, and I get the feeling that the hate comes of frustration and
pain. Certainly, I've seen plenty of similarly themed articles coming out
of
Planet Debian at one time or
another.
One of the best articles I've found yet is
One
bug report to rule them all, a humourous but altogether painfully
accurate rendition of far too many bug reports I've seen and dealt with of
the years.
A comment on Facebook yesterday got me thinking what American "traditional values" are all about. We hear it a lot, and I suspect it means something different to different people.
Here's what it means to me.
It starts with an ethic fundamentally informed by the central tenets of Christianity -- which are also excellent standards of decency by secular standards. We are called to have a relentless drive to care for the repressed, poor, downtrodden. As Jesus said, "whatever you do to the least of these, so you do to me." It means extending the hand of friendship and compassion to all, in our own neighborhood and around the world. It means taking good care of the resources we have, acting responsibly, and affirming and supporting others so they can do the same. It means that, as our founding fathers emphasized, remembering that all people are created equal, are equally deserving of a good life, and deserve liberty and freedom. Finally, it means a constant realization that we are creating a human institution, and will always have an imperfect answer to these ideals, but that we can -- and must -- recognize our faults and strive to make things better.
How do these apply to our time?
We must start with the poor, the repressed, and habitually think of their situation in everything we do. That means remembering that when we drop a bomb in Afghanistan to kill a terrorist, we also usually kill 50 innocent bystanders, and devastate their families. It means remembering that illegal immigrants from Mexico come here because all they want is refuge from drug wars, food on the table, and a roof over their head. It means showing compassion in deportation proceedings: when illegal immigrant parents have a child born in the United States, the child is an American citizen and can't be deported, but deporting the parents will create an orphan. It means actively helping the repressed people of the world, whether they be in Sudan, Georgia, or AIDS victims in Africa, Muslims in New York. It means reducing taxes on the poor, giving them the skills and tools they need to make their way in life. It means caring for those with alcohol drug addictions, helping them to summon the strength to get past those problems, rather than locking them up or throwing them out on the street. In days past, this might have meant sharing firewood with the family down the road that was at risk of freezing in winter. Today it might mean assistance with winter heating bills.
Remembering that all people are created equal means that we must provide good education for everyone, whether they live in suburban California, inner city Detroit, or rural Appalachia. We owe quality health care to everyone; those without means to pay for health care, or to pay for a car to get to a clinic, should be treated with dignity and respect, and have equal access to medicine.
Remembering that all people are created equal also means that we must provide equal justice under law, and give everyone a fair trail. We must abandon the death penalty, because we have a shocking number of people on death row -- hugely disproportionately black and poor -- that have been shown innocent of their crimes thanks to advances in DNA testing. We must maintain the integrity of checks and balances in government, and support judicial oversight over search and seizure. We must avoid warrantless wiretapping because it subverts judicial oversight and corrupts our justice system by making the exercise of power secret. We must denounce torture, and refuse to employ it, because no human, being created equal, deserves to be treated in such a way -- and we have been applying it to innocent humans.
We owe the opportunity to grow up in a loving family, in a safe community, to every child. We must make sure that gangs no longer have the run of our streets, that drugs aren't displacing hard work as the currency of the community, and that adoption is inexpensive and practical for more families, rather than costing thousands of dollars. Doing so will help every child grow up knowing that they are valued, are important, rather than being unwanted and therefore abused or neglected.
Extending the hand of friendship and compassion to all starts with being a good example -- that shining city on a hill that Reagan talked about. We have to run an open, just, and fair society ourselves. We must not fear those that are different than us, just because they're different. We have to recognize that citizens of Iran, Russia, North Korea, Palestine, and the United States fundamentally are humans, created equal, seeking the same thing: a safe and secure future for themselves and their families. Being able to coexist peacefully means starting from that point, and being willing to talk to them, and yes, even their leaders, regardless of how distasteful they may be.
Acting responsibly with our resources starts at home -- things like not driving up credit card debt, not living outside our means. The same applies to government: massive deficits each year are exceptionally irresponsible and place us at great risk both at the present and in the future. We also have a duty to care for the planet and the environment in which we live, which means actively working to curb the things we do to harm the planet and cause global warming.
What about recognizing our faults? Perhaps the most patriotic duty asked of Americans is dissent. It is never easy, but is essential to keeping our democracy functioning. This country has a long history of successes, and also a long history of failures. We failed so many by keeping slavery legal for so long, and discrimination and lynching legal for even longer. We failed that Native Americans by forcing them from their lands and treating them with brutality. We have, to some extent, risen above these failures thanks to the ability to recognize them and try, to the best of our ability, to fix them. This is what the civil rights movement was about, and why we have a holiday for Martin Luther King, Jr. He spoke out against a society that said some couldn't eat in a restaurant because of the color of their skin, or who were repressed because of their economic status. He recognized that problem in America, and by speaking out against it, helped to change this country for the better.
Today we have to recognize the things we are doing wrong, and try to change them. We are torturing potentially innocent people. We are discriminating against Muslims and homosexuals in our midst. We are giving extraordinary power to big media companies through changes in copyright law, to big communications companies through failure to enact network neutrality laws. And we are labeling people that disagree with war as unpatriotic.
Notice some things I didn't mention, such as abortion. It's not really relevant, and the lines we are fed by both sides present us with this false pro choice vs. pro life debate. In reality, it seems to me that both sides want the best for the children: for every child to grow up in a loving family, where he or she is wanted. We all know from research that laws banning abortion do not actually reduce it. So we ought all to come together and try to make it more rare by providing more support to single parents, by making it easier to adopt children, by trying to make the perceived need for an abortion to go away.
So, in this election, I look at the candidates and it seems pretty clear which one is promoting traditional values and which one isn't. Obama is actively trying to reach across the aisle and find common ground. Even in his convention speech, he suggested ways to work together on abortion like I just mentioned. In the debate, he listened carefully to his opponent and acknowledged when he thought McCain was right. This is a necessary first step in working together to move forward. McCain subsequently released an ad mocking Obama for this.
What about caring for the poor? Again, Obama's tax policies, education policies, and health care policies take care of them far better than McCain's. About responsibility? McCain supported these deficit-busting budgets of the last 6 years, supported the oil-centric energy policies, and has been only lukewarm towards dealing with global warming. McCain and Palin mock Obama for trying to help poor Chicago neighborhoods 20 years ago, for being willing to just talk to our supposed enemies, for actually reaching across the aisle.
So yes, I am a values voter, and that's why I can't possibly do anything but vote for Obama.
Currently we have a problem with the Debian list server and Gmail. Gmail signs all mail that it sends with both DKIM and DomainKeys (DomainKeys has been obsoleted by DKIM so most mail servers implement only one of the two standards although apart from space there is no reason not to use both). The Debian list servers change the message body without removing the signatures, and therefore send out mail with invalid signatures.
DKIM has an option to specify the length of the body part that it signs. If that option is used then an intermediate system can append data to the body without breaking the signature. This could be bad if a hostile party could intercept messages and append something damaging, but has the advantage that mailing list footers will not affect the signature. Of course if the list server modifies the Subject to include the list name in brackets at the start of the subject line then it will still break the signature. However Gmail is configured to not use the length field, and a Gmail user has no option to change this (AFAIK - if anyone knows how to make Gmail use the DKIM length field for their own account then please let me know).
I believe that the ideal functionality of a sending mail server would be to have the configuration of it’s DKIM milter allow specifying which addresses should have the length field used. For example I would like to have all mail sent to an address matching @lists\. have the length field used (as well as some other list servers that don’t match that naming scheme), and I would also like to be able to specify which recipient addresses should have no DKIM signatures (for example list servers that modify the subject line). I have filed
Debian bug #500967 against the dkim-filter package requesting this feature [1].
For correct operation of a list server, the minimal functionality is implemented in the Mailman package in Lenny. That is to strip off DKIM and DomainKey signatures. The ideal functionality of a list server would be that for lists that are not configured to modify the Subject line it would leave a DKIM header that uses the length field and otherwise remove the DKIM header.
I have filed Debian bug #500965 against lists.debian.org requesting that the configuration be changed to strip the headers in question in a similar manner [2] (the Debian list servers appear to use SmartList - I have not checked whether the latest version of SmartList does the right thing in this regard - if not it deserves another bug report).
I have also filed Debian bug report #500966 requesting that the list servers sign all outbound mail with DKIM [3]. I believe that protecting the integrity of the Debian mail infrastructure is important, preventing forged mail is a good thing, and that the small amount of CPU time needed for this is worth the effort.
Also the Debian project is in a position of leadership in the community. We should adopt new technologies that benefit society first to help encourage others to do the same and also to help find and fix bugs.
Share This
As some of you may or may not be aware, I'm hacking on a new build tool that has a purely descriptive language for project descriptions, with lots of sensible defaults.
Right now, the only thing I really require users to do is to declare the name and type of the project, for example
Program: foo
This will just take all files in this directory that it understands, compile them, and link them to an executable called "foo" (or "foo.exe"). So far, so good.
However, there are more complex examples, specifically those where multiple outputs are installed to different directories, for example in the case of libraries:
Library: foo
Public: foo.h, foo.c
I've omitted the library versioning stuff from the example, because it isn't necessary to understand the problem. This means "take all compilable files, link them to "libfoo.so" (resp. "foo.dll") and only mark the symbols defined in foo.c as exported (not listing code generating files will fall back to exporting everything); then install foo.h into /usr/include (or make it available as <foo.h> to dependent projects).
Now, I'd like to add an optional parameter to place a "published" resource into a namespace. How that is defined is dependent on the type of the resource (exported symbols could be tagged with a symbol version, while include files would be installed into a subdirectory of /usr/include).
And this is where I would like to get some input. How should such a declaration look like in the project description file?
The file is in RFC822 style format, with one section per project (multiple projects in a single directory are permitted if you list the inputs explicitly), and I'd rather keep it that way.
Ideas so far:
-
Public[foo]: foo.h
Public[FOO_1_0]: foo.c
This means multiple lines and dividing .c and .h files since their "namespace" attributes mean something entirely different.
Public: foo.h [foo], foo.c [FOO_1_0]
This ends up becoming pretty repetitive if I have a lot of header files.
Neither of these looks as "clean" as I'd like a new file format to look.
I'm pretty much sure "built-in" tagging of certain things will be handled by separate top-level tags (similar to automake):
User-Public: userdoc.sgml
Developer-Public: devdoc.sgml
I'm open to criticism on this one as well though.
There's a lot of debate these days about the impact of the increasing
number of paid developers in FOSS communities that started as volunteer
efforts and still have significant numbers of volunteers. Evangelia
Berdou's
PhD
thesis "Managing the Bazaar: Commercialization and peripheral
participation in mature, community-led Free/Open source software projects"
contains a contains a wealth of information and insights about this topic.
Berdou conducted interviews with members of the GNOME and KDE projects.
She found that paid developers are often identified with the core developer
group which is responsible for key infrastructure and often make a large
number of commits. Furthermore, she suggested that the groups may have
different priorities: "whereas [paid] developers focus on technical
excellence, peripheral contributors are more interested in access and
practical use".
Based on these interviews, she formulated the following hypotheses which
she subsequently analyzed in more detail:
- Paid developers are more likely to contribute to critical parts of the
code base.
- Paid developers are more likely to maintain critical parts of the code
base.
- Volunteer contributors are more likely to participate in aspects of the
project that are geared towards the end-user.
- Programmers and peripheral contributors are not likely to participate
equally in major community events.
Berdou found all hypotheses to be true for GNOME but only hypothesis two
and four were confirmed for KDE.
In the case of GNOME, Berdou found that hired developers contribute to the
most critical parts of the project, that they maintained most modules in
core areas and that they maintained a larger number modules than
volunteers. Two important differences were found in KDE: paid developers
attend more conferences and they maintain more modules.
Berdou's research contains a number of important insights:
- Corporate contributions are important because paid developers
contribute a lot of changes, and they maintain core modules and code.
- While it's clear that the involvement of paid contributors is
influenced by the strategy of their company, Berdou wonders whether another
reason why they often contribute to core code is because they "develop
their technical skills and their understanding of the code base to a
greater extent than volunteers who usually contribute in their free time".
It's therefore important that projects provide good documentation and other
help so volunteers can get up to speed quickly.
- Since many volunteers cannot afford to attend community events,
projects should provide travel funds. This is something I see more and
more: for example, Debian funds some developers to attend Debian conference
and the Linux Foundation has a grant program to allow developers to attend
events.
- Paid developers often maintain modules they are not paid to directly
contribute to. A reason for this is that they continue to maintain modules
in their spare time when their company tells them to work on other parts of
the code.
Personally, I'm also wondering why there are some significant differences
between GNOME and KDE. For example, about 67% of contributors where paid
to work on GNOME whereas only 38% were paid to work on KDE. Why do some
projects attract more commercial involvement whereas other projects
continue to be mostly volunteer based?
(Originally published on
FOSSBazaar)
There is a lot of discussion and speculation about The Singularity. The term seems to be defined by
Ray Kurzweil’s book “The Singularity Is Near” [1] which focuses on a near-future technological singularity defined by significant increases in medical science (life extension and methods to increase mental capacity) and an accelerating rate of scientific advance.
In popular culture the idea that there will only be one singularity seems to be well accepted, so the discussion is based on when it will happen. One of the definitions for a singularity is that it is a set of events that change society in significant ways such that predictions are impossible - based on the concept of the
Gravitational Singularity (black hole) [2]. Science fiction abounds with stories about what happens after someone enters a black hole, so the concept of a singularity not being a single event (sic) is not unknown, but it seems to me that based on our knowledge of science no-one considers there to be a black hole with multiple singularities - not even when confusing the event horizon with the singularity.
If we consider a singularity to merely consist of a significant technological change (or set of changes) that change society in ways that could not have been predicted (not merely changes that were not predicted) then it seems that there have been several already, here are the ones that seem to be likely candidates:
0) The development of speech was a significant change for our species (and a significant change OF our species). Maybe we should consider that to be singularity 0 as hominids that can’t speak probably can’t be considered human.
1) The adoption of significant tool use and training children in making and using tools (as opposed to just letting them learn by observation) made a significant change to human society. I don’t think that with the knowledge available to bands of humans without tools it would have been possible to imagine that making stone axes and spears would enable them to dominate the environment and immediately become the top of the food chain. In fact as pre-tool hominids were generally not near the top of the food chain they probably would have had difficulty imagining being rulers of the world. I’m sure that it led to an immediate arms race too.
2) The development of agriculture was a significant change to society that seems to have greatly exceeded the expectations that anyone could have had at the time. I’m sure that people started farming as merely a way of ensuring that the next time they migrated to an area there was food available (just sowing seeds along traditional migration routes for a hunter-gatherer existence). They could not have expected that the result would be a significant increase in the ability to support children and a significant increase in the number of people who could be sustained by a given land area, massive population growth, new political structures to deal with greater population density, and then wiping out hunter-gatherer societies in surrounding regions. It seems likely to me that the mental processes needed to predict the actions of a domestic animal (in terms of making it a friend, worker, or docile source of food) differ from those needed to predict the actions of other humans (who’s mental processes are similar) and from those needed to predict the actions of prey that is being hunted (you only need to understand enough to kill it).
3) The invention of writing allowed the creation of larger empires through better administration. All manner of scientific and political development was permitted by writing.
4)
The work of Louis Pasteur sparked a significant development in biology which led to much greater medical technology [3]. This permitted much greater population densities (both in cities and in armies) without the the limitation of significant disease problems. It seems that among other things the world-wars depended on developments in preventing disease which were linked to Louis’ work. Large populations densely congregated in urban areas permit larger universities and a better exchange of knowledge which permitted further significant developments in technology. It seems unlikely that a population suffering the health problems that were common in 1850 could have simultaneously supported large-scale industrial warfare and major research projects such as the Manhattan Project.
5) The latest significant change in society has been the development of the Internet and mobile phones. Mobile phones were fairly obvious in concept, but have made structural changes to society. For example
I doubt that hand-writing is going to be needed to any great extent in the future [4], the traditional letter has disappeared, and “Dates” are now based on “I’ll call your mobile when I’m in the area” instead of meeting at a precise time - but this is the trivial stuff. Scientific development and education have dramatically increased due to using the Internet and business now moves a lot faster due to mobile phones. It seems that nowadays any young person who doesn’t want to be single and unemployed needs to have either a mobile phone or Internet access - and preferably both. When mobile phones were first released I never expected that almost everyone would feel compelled to have one, and when I first started using the Internet in 1992 I never expected it to have the rich collaborative environment of Wikipedia, blogging, social networking, etc (I didn’t imagine anything much more advanced than file exchange and email).
Of these changes the latest (Internet and mobile phones) seems at first glance to be the least significant - but let’s not forget that it’s still an ongoing process. The other changes became standard parts of society long ago. So it seems that we could count as many as six singularities, but it seems that even the most conservative count would have three singularities (tool use, agriculture, and writing).
It seems to me that the major factors for a singularity are an increased population density (through couples being able to support more children, through medical technology extending the life expectancy, through greater food supplies permitting more people to live in an area, or through social structures which manage the disputes that arise when there is a great population density) and increased mental abilities (which includes better education and communication). Research into education methods is continuing, so even without genetically modified humans, surgically connecting computers to human brains, or AI we can expect intelligent beings with a significant incremental advance over current humans in the near future. Communications technology is continually being improved, with some significant advances in the user-interfaces. Even if we don’t get surgically attached communications devices giving something similar to “telepathy” (which is not far from current technology), there are possibilities for significant increments in communication ability through 3D video-conferencing, better time management of communication (inappropriate instant communication destroys productivity), and increased communication skills (they really should replace some of the time-filler subjects at high-school with something useful like how to write effective diagrams).
It seems to me that going from the current situation of something significantly less than one billion people with current (poor) education and limited communications access (which most people don’t know how to use properly) to six billion people with devices that are more user-friendly and powerful than today’s computers and mobile phones combined with better education as to how to use them has the potential to increase the overall rate of scientific development by more than an order of magnitude. This in itself might comprise a singularity depending on the criteria you use to assess it. Of course that would take at least a generation to implement, a significant advance in medical technology or AI could bring about a singularity much sooner.
But I feel safe in predicting that people who expect the world to remain as it is forever will be proven wrong yet again, and I also feel safe in predicting that most of them will still be alive to see it.
I believe that we will have a technological singularity (which will be nothing like the “rapture” which was invented by some of the most imaginative interpretations of the bible). I don’t believe that it will be the final singularity unless we happen to make our species extinct (in which case there will most likely be another species to take over the Earth and have it’s own singularities).
Share This
Things: