Archive for the ‘Common’ Category
I have created boycottdocker.org campaign website. Together with other software developers we feel the huge pain with that unconvenient, network principles destroying tool. It must be really good from big cloud computing corporations point of view, who run millions and thousands of containers. But I wrote all of that from ordinary not so big company with several hundred servers. Docker, kubernetes and Mesos do not help at all. Many things are impossible to do if they do not fit in their strict architecture borders: you have to spend more time on fighting with them, In most cases it is much more easier to write own shell-scripts that will automate our job as we wish, with maximal impact for our productivity, without any cumbersome cloud-specific technologies.
There was 3-in-1 event in Moscow a week ago: PGP keysigning party, cryptoparty and installfest, called Crypto InstallFest, organized by Russian’s Pirate Party. Several dozens of people have come. There were various speeches and lectures, video link and chatting with Runa Sandvik (she is involved in TorProject.org) and workshops at last. Someone was helped with Ubuntu installing, someone with PGP (GnuPG of course). Also there were many discussions about cryptocurrencies and Bitcoin (I can not call it cryptocurrency). There are some dicussions and photographs in social networks: Vkontakte, Facebook.
Several days ago I decided to make an alternative for OpenVPN: GoVPN. OpenVPN uses rather slow HMAC for message authentication and no zero-knowledge password authenticated key exchanges. He is pretty simple, but with not so high security margin and performance.
I wrote already working (but of course with possibly many bugs) daemon on Go programming language. It uses one of the faster crypto algorithms available today and achieves zero-knowledge mutual pre-shared key authenticated key exchange. All derived keys are per-session, so even if PSK is compromised, there is no way to decrypt captured traffic (perfect forward secrecy property).
It does neither interface nor IP-address and routing management: it is the task of underlying OS facilities. And currently it can work with only single client. But I am planning to fix that: so it can be used with many clients simultaneously. Moreover secure remote password can be better choice to allow humans use memorable passwords instead of 256bit keys.
I think that the main comparative advantage is small code size, that can be easily analyzed, audited and fixed. From technical point of overview: it uses Salsa20, Poly1305, Curve25519 and DH-EKE with PSK.
Go programming language seems to be very interesting for me. I used to program several years on Perl, Lua and last time on Python. Go is like C, but with convenient necessary features I wished for. I have never coded on it before (except two half-screen sized functions) and this weekend is the first time I decided to write something useful.
As XMPP organization killed global Jabber network (requiring TLSed interserver connections), I looked for good global chatting solution. (Un?)fortunately only IRC protocols seems to be simple enough and there are clients for every available platform I presume. Big global IRC networks are not protocol compatible between themselves. Existing IRC daemons are not so easy and quick to setup. Anyway even in XMPP world there are islands of separated servers, so even if my server can not communicate with other ones — so be it.
I used miniircd IRC daemon: it is written on Python, does not have configuration files and satisfies all my IRC needs. But as I decided to try Go: I rewrote it. Single executable binary and pretty fast working daemon with ability to save logs and channel states. https://github.com/stargrave/goircd
I still did not cover all it’s commands with unittests (however I began with TDD development principle, I wished to chat with my friends stronger), so probably there should be bugs. And as I do not have any experience in that language: bugs have to exists. Currently it works pretty well for private/personal use. You can easily create TLS connections with crywrap utility. And of course it is free software!
There was rather big cryptoparty in Moscow several days ago. As for me: it went rather good, because there were people satisfied with software they used (not convinced before) (proven enough TrueCrypt, GnuPG and Pidgin’s OTR plugin) and with newly installed proven enough dm-crypt/TrueCrypt, GnuPG and Pidgin’s OTR pluging privacy saving software. Not only privacy related issues were talked about, but cryptoanarchism related too. Some kind of theoretical lecture, software installation workshop lasted for nearly four hours. After that there was rave music afterparty. Many kudos to organizers (perfect but good enough for the first time for so big audience) and people interested in their own privacy and anonymity issues. Hope most of them enjoyed it and will visit the future ones.
Here is my more descriptive opinion and answers to some critique, unfortunately on russian.
Хотел бы высказать своё субъективное мнение о том как недавно прошла криптовечеринка в Москве (хотя я конечно не нейтральная сторона, но подготовкой занимался в меньшей степени нежели чем другие). В сторонних блогах в основном негативные отзывы типа “хуже некуда”, “полный fail” и тому подобное. И я скорее полностью не согласен с этим. Возможно люди просто преувеличивали, или слишком многого и невозможного хотели в противном случае.
Какие же назывались провалы:
- вступительные речи с “мы сами будем искать и наказывать преступников”. Да, это безусловно цензура, это проявление чего-то авторитарного, против чего как-раз таки шифропанки и борются. Однако даже я (а я умею придираться) решил плюнуть на это, ведь понятно что хотели передать факт того что шифропанки всё своё делают не для того чтобы покрывать преступников, им тоже всякие гады противны, но любая технология будет всегда нести как добро, так и зло. Злоумышленники (которые хотят лишить нас приватности) всегда будут показывать только плохую сторону.
- вступительная речь с “facebook, email уже более не безопасны” тоже конечно призывает вопрос “а когда они были и кто считал что они когда-то такими были?”, но, опять же, лично я решил не придираться и вполне поверю что большинство не технарей серьёзно были уверены в обратном и Сноуден их наверное шокировал, хотя он просто подтвердил факт что да — никаких предположений, за вами следят и прослушивают
- гораздо более серьёзно это то что демонстрировалось проприетарное закрытое ПО (Microsoft Windows, Adobe Reader) и использовались сервисы абсолютно неуважающие приватность (Google+) для видеотрансляции и организация проводилась в Facebook. Это бесспорно неправильно, но Михаил не раз отметил для пришедших что надо использовать только и только открытое и свободное ПО по возможности. Сразу спрыгнуть со своих MacOsX и iOS на FreeBSD или GNU/Linux не каждый может. Лично я попросил прощения за демонстрацию с Adobe-ом, но она не нарушала ничью приватность и чтобы людей не задерживать ещё больше и мне не заниматься доставанием своего правильного свободного компьютера — решили сэкономить время. Хотя позволить себе создавать презентацию вне LaTeX/beamer я не мог. Но делалось же это всё в попыхах и впервые и чтобы уж наверняка: решили немного отойти от правильного шифропанковского ПО и сервисов на первый раз
- не отрепетированное вступление. Ну да, было такое. Было даже забавно. Первый блин комом, намотали на ус. Это всего лишь пять минут попытки вклинить нечто что привлечёт больше людей, нежели чем только технарей пришедших пообсуждать BitCoin-ы
Во-первых у нас не Германия, где люди реально на полном серьёзе обеспокоены своей приватность. У них, как говорят, реально наказывают за нелегальное использование BitTorrent-а. У нас даже сложно представить как это и у нас люди особо то и разницы между свободным и свободнораспространяемым ПО не знают. То есть у нас не знают цену приватности (так как её ещё не теряли в таком объёме) и менее образованы. Устроить в зале массированное обсуждение за и против сервиса Cryptocat у нас ещё банально рано.
Во-вторых организаторы очень правильно и не раз подчеркнули что целевая аудитория это, грубо говоря, домохозяйки с Интернетом, которым и надо показать возникающие опасности и как их можно побороть на пальцах. Михаил во время workshop-а, как мне показалось, правильные давал рекомендации, показывал разносторонний софт (почему OTR лучше других и какие у него недостатки, альтернативы проприетарным облакам), демонстрировал воочию на практике работу SMP, призывал кооперировать друг с другом. Ко мне подходили люди и интересовались силой, актуальностью, приемлимостью TrueCrypt, PGP и GNUnet софта. Устроить массовое цокание по клавиатурам технически было невозможно, так как меньшинство пришло со своими компьютерами и целью посещения криптопати было явно не обустроить свои инструменты и средства связи шифропанковским софтом.
В-третьих организаторы решили устроить нечто большее чем загнать людей в помещение с проектором и микрофоном и изнасиловать их технику чтобы АНБ/ФСБ не добралась до неё. Вместо темы только шифропанков затронута и криптоанархия, в общем-то не упоминающейся в других странах. Создана атмосфера, музыкальное сопровождение, попытка представления. Устроили afterparty rave, но не могу его оценить так как поклонник куда более тяжёлой и экстремальной музыки.
Без них не было бы ничего, особо бы никто не почесался. Первый блин комом, но все учли ошибки. Как и первый сексуальный опыт — он может показаться не совсем тем что ожидалось. Но самое то главное: оттуда вышли люди с установленным софтом, вышли люди понимающие необходимость протоколов социалистов миллионеров, вышли люди переживавшие за юзабельность TrueCrypt и реализаций PGP? Значит бесследно или впустую не прошло. Можно (и нужно) лучше, но для первого раза более чем отлично.
I was FreeBSD user for six years and worked with it’s versions from 5.0 to 7.0. There appeared to much work with GNU/Linux related subsystems exclusively and it was easier for me to switch yet another UNIX-like operating system temporarily.
I tried several distributions but stayed exactly on Debian. My requirements were:
- mature, stable and reliable system without any bleeding edge software. I do not worry that there is no latest version of Firefox for example. Included in stable Debian’s distribution one fully satisfies me. Maybe it is not so fast as can be, but it is mature and working.
- less or more permanent distributions overall architecture without any sudden surprises after yet another packages upgrade. Of course sometimes it can not be skipped, but serious changes are always must be in a major software/distribution version that is rather seldom event.
- big collection and wide availability of various software. Debian has one of the biggest packages collection. And all of their binary compiled versions can be easily installed using single command. Of course you must trust it’s maintainers. I trust and rely on them.
- it’s basic installation should not have anything that I am going to remove as a first step. Just minimal bunch of tools and daemons. Ubuntu for example does not provide that: I have to remove huge piles of GNOME-related things and only then install my preferred ones.
Debian even now is the single distribution that can fit in those requirements. But several weeks ago I was very disappointed hearing that most part of it’s developers support integration with systemd.
You see, modern GNU/Linux-es are not a UNIX-like OS with UNIX-way hackerish concepts anymore. UNIX-es in my opinion always were very beautiful and smart programmers creations with really very elegant tasks solving. Most GNU/Linux-es lost that property.
Several decades there were quite few interprocess communication choices. Most time it is either plain text or, unfortunately, binary data floating between conveyors, pipes, domain or network sockets. Each daemon representing any subsystem can be less or more uniquely determined by socket path of pair of network address and port. In nearly all cases it can satisfy anybody.
Even at the very early days of UNIX systems hackers preferred plain text and similar driven protocols and file formats. Though rather relatively big SMTP responses are not as good as binary ones could be, exceptionally on that time slow links, hackers preferred human readable choices anyway, because they are simple, easy to debug, easy to maintain and easy to use.
But GNU/Linux does not like idea of beauty clever decisions and long time proven software. It’s developers (I can not call them hackers in most cases anymore) have to invent the wheel again and create yet another incompatible solution like several IPCs before and DBus itself. It requires heavy dependencies, it does not use well known socket-like paths and addresses, it uses unreadable binary protocol, it is slow and does neither guarantee any delivery nor has any buffering queue.
Access to various low level hardware devices used simple device node filesystem-like access. Of course many of them dictate standards existence and audio has one: Open Sound System, represented by entries inside /dev. Easy to use, easy to implement proven and mature system. If you want to stream audio data other the network you can easily use UNIX power to connect it for example with either pipe or network socket.
GNU/Linux folks do not understand that elegant solution and invent ALSA, aRts, ESD, NAS and PulseAudio at last. So many reinvented creations for rather simple thing. Of course OSS is not the right solution if you have to mix various sound inputs and outputs of both hardware and software modules. But JACK does this job pretty well. GNU/Linux developers do not think so again.
What about operating system’s initialization part? You have various daemons that should be started and controlled. You have to do various file system related steps, manage process execution somehow. All that tasks are done for a long time using shell interpreter, intended to solve them. As a fact each daemon has small shell script used to control server’s behaviour. Hackers need to glue those daemons together. For me, it seems to be very elegant solution to include trivial plain-text metainformation as script’s comments and to create symbolic links dependent on that metainfo with number included to force sorting done right, as in System V.
UNIX-way is to have many small tools, where each of them does single job, but does it well. Simple separate initialization system, simple separate logging system, simple separate shell interpreters, simple IPC socket-oriented libraries, simple daemons, cron, inetd and so on. Looks simple, clear and nice.
You are wrong! Modern GNU/Linux-es can not accept that, because they are missing written on compiled language (does not depend on already existing software for controlling process flows (shells)) program, with own IPC dependency, with own declarative language bloated combine of initialization, logging, cron/at-ing, inetd-ing and DBus/socket listening systems at once. Wait, systemd is pretty modular: several dozens of separate executable. Hackerish SysV is just a shell interpreter with several shell-scripts. Thirty years ago logs have been written on rather small hard drives in plain text, but today seems that hard drives became much smaller and more expensive and systemd decided to write human unreadable and unprocessable with any kind of sed/awk/shell/perl tools binary logs.
I still do not understand why GNOME and derivative distributions (I am sure that udev, systemd, dbus and GNOME are single aggregate) does not use very simple mailcap-files to decide what to do with various kinds of data. mailcap contains plain text lines with data content type and shell script code saying what program you need to run and apply to data. Just find the line by it’s content type and execute related command line. This can be done with single sed call. Just simple plain text file to rule all user’s software preferences. GNOME has to prerun software that will register itself on DBus (should be already running), then another software must create proper message, send it over DBus hoping that someone with catch it doing probably what user wants. It is awful.
And at last I see in Debian maillists that they are going to remove local sendmail server. I see what is happening: when systems are created by very clever hackers — they are very cool for educated technicians and other hackers. When ordinary labour crowd is falling in this world: it will be ruined. Usenet was destroyed like that. Email etiquette has mostly disappeared and replaced by top-posted huge quoted HTML messages, after user-friendly email clients born.
Security is not compatible with user-friendliness. Simple clever hacks are not compatible with classical user’s world of view. Developers never speaks users on the same language. There is always separation of developer-friendly and user-friendly. They can not coexists together, as like servers are pretty different from desktops.
Current Debian is very developer and server friendly system, while Ubuntu is aimed to be user-friendly. Systemd is great for desktop requirements, so let’s integrate it to desktop system. Why one is going to replace cron/at, SysV/rc, inetd, sockets, syslog, devnodes with single all-in-one bloated monolithic combine and remove sendmail? What will stay from UNIX itself? Arch Linux is going to mess /bin and /sbin with /usr/bin. So I won’t even find /bin/sh in that OS. It is not UNIX-like system anymore. It is yet another unmaintainable crap of compiled monolithic POSIX-compatible (hope so) code.
Of course there are really true hackerish UNIX-like GNU/Linux distributions, but all known ones require much manual work with them. Free software *BSD does not, as it has cool port collections and well maintained high quality overall system’s design (not a pile of absolutely different software pieces).
At last I realized that zsh shell is really much more useful and better to use than either tcsh or far much than bash. Many shells provide different very cool features, that looks like a killing feature, but in most cases, for me, all of them are in seldom use. tcsh has plenty history substitution options, as bash has large quantity of parameter expansion techniques. But I hardly use even a small piece of them. Of course they can greatly reduce overall character input count, but are too bloated to remember.
One of the most often mentioned zsh‘s feature is it’s commands completion. It is convenient possibility to use fancy menus to either select process you are going to kill, or git’s subcommand to execute. Or maybe just to choose corresponding directory or filename. Well, sometimes, in my opinion, this can be pretty useful, but character count during those menus exploration in most cases, visual analyzing of all those entries leads to too high interaction (human with computer) delay and I will enter two more characters of filename and complete it with Tab faster. Entering filename’s part and hitting Tab is one context, but looking for necessary entry is uncomparable another one. Context switching is an expensive operation.
Moreover all those completions can be very relaxating: you will forget your files hierarchy, forget what options does command have, forget what targets exist in your Makefile, forget how to easily automate PID saving and killing by it, forget how to either make cool shell aliases or write yet another extra useful small Perl-script. Of course there is no distinct border of those unskilled relaxation: if there is file “foo” and “bar”, then obviously there is no need to force hacker typing it’s fullname. Remote SSH directories transparent observation and completion is another undoubtedly useful feature. But all of those completions exist in other shells except zsh.
Anyway there are some killer features that made me zsh hard fan and currently no word about switching back to either tcsh or bash. Here they are:
- multiline editing capabilities are extremely useful without creating many temporary one-time separate shell-scripts. And of course you can easily edit them inside external text editor.
**/*-like various path expansion that saved me from huge quantity of find occurrences and together with
*(.)-like things your will forget about it in most cases at all. I had several aliases and external shell-scripts, all calling find, but now throw them out.
- command spellchecking — tcsh already had this feature, but bash did not. With high speed typing, error rate is pretty high too and this feature can save much time and nerves.
- autopushd possibility — each cd to directory acts like pushd and you can easily travel back like in your browser. This feature is particularly useful together with Z plugin.
- autocd option is also presented in bash. It is under a big questions of usefulness, as ambiguity may appear too often with it. With this option you can suppress cd before directory name and shell automatically understands that you are going to change it.
- filename extension related aliases that saves a lot of time from entering zathura to view PDF files, sxiv for images and so on.
- it is much faster than bash. Without turned off unused extensions it starts faster, runs faster, completes faster. Each dozen of milliseconds are nice to spend not awaiting for many-bogomips powerful computer.
And there is separate killer must have plugin that I met firstly when using bash (it also works with zsh of course): Z directory jumper. It tracks each time you change directory and offers quick jumping to previously visited place identified by regular expression and directory visiting frequencies. And it works perfectly with autocd and autopushd.
zmv feature looks very promising and seems that it will replace another bunch of Perl/shell-scripts from my computer. However it requires some learning curve of course.
There are plenty of reasons why I still do not understand why people like Gmail’s webmail so much and are ready to replace powerful desktop email clients.
No threaded conversation view
There is no threaded conversation view. What a hell!? Even simple mailx under every modern GNU/Linux distribution can display messages in threaded view. Email nature itself, it’s In-Reply-To, References and similar fields assume that any conversation can be a graph like, not linear. Of course you can create really linear thread, where every next message is In-Reply-To the very first threaded starting. But Gmail does not do that and In-Replying-To the message you are really currently answering.
I think that root of that “problem” lies only within huge quantity of cyberspace newcomers, that are not capable of serious long-term discussion with many new questions arising during it and that have to be separated from the main thread. Those people mostly have never met situation where technical discussion may lead to completely different and more important various subjects. Most of them tend to mix unrelated discussion subjects in single letter.
It is just simple lack of discussion experience. Of course either instant messaging or IRC chatrooms have nothing similar and they offer just a raw one huge heap of short messages. It is chatting, nothing more and that behaviour is acceptable there. But email was born as a powerful tool of convenient conversation without big piles of weakly referenced messages with low total overall signal-to-noise ratio. For over several dozens of years this email nature have never been seriously changed, because it is really cleaver and fine. So many hackers can not be wrong.
Google turned it to yet another instant messaging system. It does not use specific protocols like XMPP for that, but SMTP one. It destroys all graph-like structures by their linearization. Newcomers just can not learn how to deal with real serious discussions (like hackers do), because they do not have an instruments for that.
Ignoring of In-Reply-To header fields
Gmail does not look for In-Reply-To messages fields to determine if it is starting of a new thread. If you change message’s subject (just to clarification for example), then it will be recognized as a new thread, however you clearly tell in In-Reply-To field that this is reply to exactly that message of the same thread, not another one. Long-term discussion thread with several branches is divided to unrelated isolated linear conversations, however headers did not allow this behaviour.
Lack of headers control
Moreover you can not control your own message headers. You can not forcefully split thread (removing In-Reply-To and keeping subject same). You can not join mistakenly dismembered thread. You can not use some mailing list management software that is controlled through message headers fields. You can not add just simple informational fields, for example just to mention your your PGP public key’s availability.
Lack of any maillist related functionality
As mentioned above, there are no “thread split” and “threads join” actions. Also there is no “reply to list” buttons. Just only trivial “reply” and “reply to all”. This is the reason why people send messages twice to one recipient so often (duplicating it through already including maillist and by CCing him simultaneously). Gmail have no ability to show either are you subscribed to a maillist and there is no need in separate reply message intended for you, or you are not subscribed and should be CCed. It does not support Mail-Followup-To header. You can not add it, because you are not allowed to edit headers. You can not take it in action non manually, because there is no “list reply” functionality, again.
There is no such powerful thing as message scoring. But many desktop email clients lack this feature too. You can specify various rules that alter message score. You could sort all correspondence by this score, leaving trivial notifications at the bottom and moving to thrash after reading. You could easily wipe unneeded messages, could easily find important things. Gmail’s mailboxes are just a huge heaps of equally scored letters.
Supporting obsolete RFC standards
Gmail encodes attachment’s filenames in obsolete RFC2047, instead of modern and everywhere supported RFC2231. I said everywhere? Of course with exceptions: Microsoft Outlook products will never be on a technologies bleeding edge. Gmail seems to be on the same way.
Gmail does not allow you to send Windows executable binaries of any kind in any form even when using it without webmail interface. Even if you will change attachment’s Content-Type, filename’s extension, put it in archive, compress that archive. They say that this is because of security. Why are they making decisions of that will be secure for me? Who the hell they are? It is my choice, my problems and my responsibility to send my own compiled binaries to someone awaiting for them.
- Unability to forward message as valid correct RFC822 email attachment, keeping all headers and attachments as is.
- You do not know how spam-filtering works and you can not adjust and control that blackbox.
- No regular expressions support or complex search queries (comparing for example with Mutt). But I agree that this is seldom actions for most of us.
- No way to either specify or override attachment’s MIME type.
- You can not send just single file/attachment. It always will consist of an empty text part and an attachment itself.
- No possibility to turn of line wrapping, for example either to insert patch/preformatted text contents as is or draw ASCII schemes.
And of course an obvious lack of PGP de-facto standard for privacy greatly reduces all potential usage possibilities of that webmail.