Igorette igorette@identi.ca

Wow, I haven't used this service in a long time

Debian has been moving away from strong ownership of packages by package maintainers and towards encouraging group maintainership, for very good reasons: single maintainers have a bad bus factor and a number of other disadvantages.

When single maintainership is changed into maintainership by a small¹, open group of people who can easily communicate and sync with each other, everything is just better: there is an easy way to gradually replace people who want to leave, but there is also no duplication of efforts (because communication is easy), there are means to always have somebody available for emergency work and generally package quality can only gain from it.

Unfortunately, having such group of maintainers for every package would require more people than are available and willing to work on it, and while I think it's worth doing efforts to have big and important packages managed that way, it may not be so for the myriad of small ones that make up the long tail of a distribution.

Many of those packages may end up being maintained in a big team such as the language-based ones, which is probably better than remaining with a single maintainer, but can lead to some problems.

My experience with the old OpenEmbedded, back when it was still using monotone instead of git² and everybody was maintaining everything, however, leads me to think that this model has a big danger of turning into nobody maintains anything, because when something needs to be done everybody is thinking that somebody else will do it.

As a way to prevent that, I have been thinking in the general direction of a Cat Model of Package Ownership, which may or may not be a way to prevent some risks of both personal maintainership and big teams.

The basic idea is that the “my” in “my packages” is not the “my” in “my toys”, but the “my” in “my Cat, to whom I am a servant”.

As in the case of a cat, if my package needs a visit to the vet, it's my duty to do so. Other people may point me to the need of such a visit, e.g. by telling me that they have seen the cat leaving unhealty stools, that there is a bug in the package, or even that upstream released a new version a week ago, did you notice?, but the actual putting the package in a cat carrier and bringing it to the vet falls on me.

Whether you're allowed to play with or pet the cat is her decision, not mine, and giving her food or doing changes to the package is usually fine, but please ask first: a few cats have medical issues that require a special diet.

And like cats, sometimes the cat may decide that I'm not doing a good enough job of serving her, and move away to another maintainer; just remember that there is a difference between a lost cat who wants to go back to her old home and a cat that is looking for a new one. When in doubt, packages usually wear a collar with contact informations, trying to ping those is probably a good idea.

This is mostly a summer afternoon idea and will probably require some refinement, but I think that the basic idea can have some value. Comments are appreciated on the federated social networks where this post is being published, via email (valid addresses are on my website and on my GPG key) or with a post on a blog that appears on planet debian.

¹ how small is small depends a lot on the size of the package, the amount of work it requires, how easy it is to parallelize it and how good are the people involved at communicating, so it would be quite hard to put a precise number here.

² I've moved away from it because the boards I was using could run plain Debian, but I've heard that after the move to git there have been a number of workflow changes (of which I've seen the start) and everything now works much better.

At LibrePlanet, Seth Shoen demonstrated Let's Encrypt to obtain and install a new TLS certificate with a single command in only a matter of seconds. Will be awesome when it's live.

Why a free automated certificate authority is not the solution

The answer is simple: It's a certificate authority.

The certificate authority system is inherently flawed, this was not only proven by the fact governments as well as criminals could take over broadly accepted certificate authorities in the past, or that these takeovers had to be patched by software updates of a myriad of browsers, operating systems and other software.

It is flawed because it has that huge attack vector, there are over over 50 organizations that are trusted by your browser and they gave out the privilege to issue certificates for any domain to hundreds of other organizations. Remember this model is about trust. Do you trust all these or even the 50 root CAs? Did you verify they properly handle the power they've obtained? I did not, it's too much work.

Adding just yet another organization that can issue certificates for any domain only strengthens that model. It ensures future revenues for the companies providing you the nice little green icons in your browser, called "extended validation". I will leave looking up the prices for such a EV certificate and the estimate of how much real man work goes into that as an exercise for the reader.

There's hope though. For a few years now there's a new standard in the making, called "DNS-based Authentication of Named Entities", DANE for short. It's based on DNSSEC, an effort to prevent forged and not authoritative answers in the DNS system. In short DNSSEC guarantee's that the IP you're connecting to is controlled by the owner of the domain and DANE guarantees that there's no middle-man in your connection to the webserver listening on that IP.

DNSSEC reduces the number of entities you have to trust to effectively one, IANA. IANA does contract third parties to operate the root zone, currently this is VeriSign. Every signature can be chased to that single trusted party. To forge a domain you would need to compromise the root zones key, which is guarded by high standards, much higher than the ones of your average certificate authority. Also if you compromise at that level, you need to mirror the infrastructure of the whole top level domain your target domain is part of. This is feasible but also visible to monitoring systems. Attacking a top level domain infrastructure directly is also possible, the effect is greatly reduced though, only that single top level domain is compromised. You can't change the keys here either, as you would need to update the signatures in the root zone. And again an attack is more visible here.

Whether this is really greatly reducing the attack vector is debatable, what it objectively reduces is the damage you can make. Remember to compromise the current system on a whole you just need one of the hundreds of little certificate authorities.

You can activate DANE validation today through an excellent browser extension provided by the Czech domain registry. After you have installed it you can see that all my sites already deploy it, it's certainly possible.

I can understand if companies that benefit from the current system embark in such a "free" registry. I can understand if the EFF supports such a system as a short term measure, they don't directly influence any of the major software systems that would need to be adapted.

What makes me angry is that Mozilla is spending a lot of money to support it, while completely neglecting DANE support. There's no real progress for years now. They support the old broken system while they really could change something. If a major browser vendor like Mozilla shipped DANE support, across all its products, it would boost adoption of it a lot.

#mozilla #ssl #dns #dnssec #dane #letsencrypt

via Jonne Haß - link

I think there's a lot of value for an OStatus bridge for pump.io.

Calling all our wonderful podmins!

It appears that someone has been spreading false information to podmins around the network, suggesting that podmins of smaller pods close down their pod because of some current issues with federation. This is rubbish, and these statements are not endorsed by any "official authority".

It's true that diaspora* has some issues with distributing content effectively throughout the network. Some comments or likes may not appear on all pods, and occasionally an image may appear twice. But there are people working to solve these issues.

Closing small pods wouldn't help these issues at all. diaspora* is a decentralized network which will only keep growing and stay healthy if the number of smaller nodes in the network keeps increasing, as it has been. That's why the software is open and available for anyone to install and run. Small pods are not a problem at all; in fact, the network needs small pods to keep improving. It's some of the very large pods which tend to have some problems with federation, because of the high traffic flowing in and out of them. diaspora* wasn't designed to accommodate such huge pods, and so podmins of some of our largest pods face some difficulties to keep performance at an optimum level.

To keep growing and becoming healthier, diaspora* needs more small pods, not fewer. The ideal that we'd like to work towards is where diaspora*'s membership is widely and more evenly distributed around a huge number of smaller pods.

If you are thinking of setting up a pod, either just for yourself and friends or as an open pod, don't be put off by anything you might have read recently saying that small pods are a problem. They are part of the solution!

And if you are running a pod of any size, large or small, you are one of the people who is keeping this network alive! Don't listen to anyone who tries to tell you any different. You are part of the beating heart which makes diaspora* awesome! We love you!

#diaspora #podmin #podmins #announcement

via Diaspora HQ - Link

Version 0.4.0 available for Linux & Windows: http://terminal-overload.org #tol #free #opensource #floss #indie #fps #game #linuxgaming #torque3d

Terminal Overload

Latest news: Oct. 12 2014: Version 0.3.1 is available for Linux and Windows. What's new?

Just learned about a massive git-annex deployment, spanning multiple organizations, 100 terabytes of data, and with complications including mailing hard drives, Debian VMs on Windows, and custom GUI interfaces. Hoping I can share some details sometime, it's awesome!

The really great thing about it is that when they're older, my great-neice and nephew will quite likely at some point use some of this data. This is all about preserving an important part of their cultural heritage.

Black Mirror: http://www.imdb.com/title/tt2085059

6 episodes. Watch it!

#Technology #HCI #SciFi #AugmentedReality

"everything is a stream" -> http://blog.rivva.de/everything_is_a_stream #rivva

The rich client for Pump.io

or other options via the website

Bug

• [IMP-88] - Cannot post full-res photos
• [IMP-92] - java.lang.IllegalArgumentException: Activity PostActivity does not have a parent activity name specified.
  

Improvement

• [IMP-93] - Better image loading performance

New Feature

• [IMP-91] - Tablet UI

Oh wow cool!  First "in the wild" use of PyPump?  PumpMigrate... migrate between instances!

https://gitorious.org/pumpmigrate

How long did it take for migration tools to appear for StatusNet?  It's awesome to have them so soon for pump.io!

langsam könnte sich meine alte timeline mal wieder blicken lassen.

There seems to be a problem with the password recovery on identi.ca. I'm trying to trace it down; I think it might have to do with firewalls and the remote mail server.

Thanks for being patient, folks.

Luckily, my flight is delayed, so I have some time to look into this.

Pump Issue #1: 'The Social Web is not federated' - http://ur1.ca/eb86m

Twitter sperrt Flattr. Begründung: Die Favs unserer User gehören nur uns. http://ur1.ca/deix0 Merkt euch das, wenn ihr favt.

The wikipedia list looks even better: http://en.wikipedia.org/wiki/List_of_Open_Source_Android_Applications !android !replicant

The new release candidate "Lazy Sunday is out: http://ping.fm/kqCzu /al