Geekices

Trying out Emacs again

A few days ago, I decided to give Emacs another try. I’ve previously attempted to use this text-editor / operating system — probably about 10 years ago or maybe a bit more — but never got the hang of it.

A few years after my first try at Emacs, I discovered Markdown. Since then, I’ve used text editors with a GUI to write in this markup language. That was until two years ago when I encountered a Vim mode for Markdown and adapted it to my specific needs. It has been one of my main tools to write, but I don’t really like the Vim keybindings.

After a bit of pondering, I thought about giving Emacs another go, mainly because the shortcuts are similar to the ones used by Tmux and I felt this would make my adaptation to the editor easier. But to do that, I would need to read about this software, given its complexity. That’s how I got to an amazing reading resource: “Emacs Mini Manual (PART 1) – THE BASICS”. If you want to learn how to use Emacs, give it a go; it’s really useful.

One thing about Emacs is that it feels bare-bone when compared to some editors. This is not true, of course, but for a newbie like me, it might as well be because most of the options are “hidden” and you need to know how to get to them.

After reading the “Emacs Mini Manual” and some other resources sent to my by folks at Twitter and at Fosshost’s IRC channel, I decided to try an Emacs distribution to help me use this software. That’s how I got to Prelude.

Prelude is an enhanced Emacs 25.1+ distribution that should make your experience with Emacs both more pleasant and more powerful.

And it really does. It has some themes, avoiding the eye-hurting default white background, and includes several plugins to ease your life. Also, you can configure it as you like, just like vanilla Emacs.

To try this distribution, I decided to write this blog post after setting it up. So far, so good.

PS: It’s almost time for EmacsConf.


Geekices

Comissão Europeia prepara possível ataque às comunicações encriptadas

O Financial Times teve acesso a uma alegada nota interna da Comissão Europeia que visa expandir o “acesso legal direcionado” às comunicações eletrónicas encriptadas como forma de combate às redes de pedofilia, terrorismo e crime organizado.

A intenção, de acordo com a nota, é incentivar a discussão entre os estados membros para os entraves que a encriptação coloca na investigação e condenação de criminosos.

A nota contém alegadamente o seguinte, de acordo com o jornal norte-americano:

The application of encryption in technology has become readily accessible, often free of charge, as industry is opting to include encryption features by default in their products[…]. Criminals can make use of readily available, off-the-shelf solutions conceived for legitimate purposes. This makes the work of law enforcement and the judiciary more challenging, as they seek to obtain lawful access to evidence.

O intento parece ser a introdução de backdoors para permitir às forças de segurança contornar a encriptação e ter acesso aos conteúdos que, de outra forma, estariam encriptados. Na prática, aplicações como o WhatsApp, Telegram e Signal, que usam sistemas de encriptação para as comunicações dos seus utilizadores, seriam legalmente obrigadas a ter esta “porta dos fundos”.

Este tipo de ideia já não é novo. Em dezembro, o procurador-geral norte-americano, William Barr, sugeriu algo idêntico e classificou essa intenção como sendo de alta prioridade para o sistema de justiça do país.

Uma porta aberta a todos

A introdução de um backdoor para as forças de segurança significaria também que qualquer grupo criminoso, agência de espionagem, regime ditatorial ou pessoa mal intencionada também conseguiria esse mesmo acesso.

Não é possível que essa porta dos fundos esteja apenas acessível às forças de segurança porque não é desta forma que a encriptação funciona. Encriptação é matemática e alguém com conhecimentos técnicos e poder computacional suficiente poderia – e provavelmente conseguiria – descobrir a fórmula usada no sistema de encriptação, conseguindo assim aceder também às comunicações porque não há sistemas de encriptação infalíveis.

Um sistema de encriptação, por muito bom que seja em teoria, está sempre sujeito à qualidade da sua implementação, a falhas de segurança do hardware onde é utilizado e aos avanços tecnológicos que vão surgindo.

Ou seja, esta intenção da Comissão Europeia, a ser verdade e a passar a legislação, é um tiro em cada pé e outro na cabeça, figurativamente falando.

A acontecer, uma medida destas não seria muito diferente de obrigarem tudo e todos a manter as portas de todas as casas e de todos os edifícios sempre abertas, para que as autoridades consigam mais facilmente detetar ilícitos como violência doméstica e roubos, e depois queixarem-se de que há um aumento no número de assaltos.

Uma não-solução para criar mais problemas

Se esta intenção algum dia transitar para legislação, nada impede os grupos criminosos de desenvolverem os seus próprios sistemas de encriptação, algo que provavelmente já fazem. Ao invés de resolvermos um problema, estaríamos apenas a fragilizar fortemente o direito à privacidade dos cidadãos.

A alegada nota da Comissão refere, contudo, que o acesso às comunicações encriptadas deve ser proporcional e direcionado a um indivíduo ou grupo no contexto de investigação criminal. Apesar disso, tal não impediria que alguém numa posição de autoridade utilizasse este acesso para benefício próprio ou prejuízo de outrem.

Um político no poder poderia utilizar este backdoor para prejudicar os seus rivais. Um agente de autoridade envolvido num caso de violência doméstica poderia perseguir assim o conjugue.

Custo alto, benefício baixo

Há muitos potenciais problemas para pouco benefício. As autoridades continuam a conseguir apanhar criminosos sem necessidade de backdoors. Veja-se o que sucedeu quando a EncroChat, uma empresa holandesa muito procurada por redes criminosas devido ao desenvolvimento de equipamentos e sistemas de comunicação encriptados, foi desmantelada, tendo levado à prisão de várias pessoas envolvidas em atos ilícitos como tráfico de drogas.

Até onde estamos dispostos a ir e quanto queremos sacrificar da nossa privacidade em nome da segurança?

A imagem de destaque do artigo é da autoria do site Pexels e está sob a licença CC0.


Geekices

Updates on Userrepository and Jarvis

Lately, I’ve been having some problems when building picom-ibhagwan-git and picom-tryone-git. The first one would build OK, but not the second one.

After a bit of debugging, I found out that it was a problem related to the way makepkg and git handle the cache when building these forks. This would also happen when adding the picom-git package: it would build because it’s the first package in alphabetical order and Jarvis builds the packages that way, but not the other two.

To fix this, the build() function no longer uses pushd and popd, allowing the script to work outside the package directory it’s building and delete some parts of the cache folder Jarvis uses.

This has the upside of allowing a better cache cleaning when building the packages. In a future commit, it will clean after itself better, up to a point it cleans every cache and artifact generated during a build.

And yes, $HOME/.npm and $HOME/.cargo I’m looking at you both.

There will be an exception, though: the makepkg.log file in every submodule folder because I use it as a log file for the package build.

Unrelated to this issue is the removal of the onivim2-git package. It takes some time to build and lately it would ask human intervention to confirm some steps, which is not compatible with the way Jarvis builds the packages and because the script is meant to be a tool to build the packages in an automated way.

One last thing: please become a Patron if you want to support userrepository.eu. Even €1 will help cover the monthly expenses, just over €15. If I get enough patrons, I’ll be able to upgrade the virtual machine to one with better specs, which will allow a higher package compression level, shorter build times and maybe even packaged kernels. Thank you!


Geekices

Some statistics for Userrepository

You might have noticed that Userrepository uses Cloudflare. I chose it for two main reasons: their ability to help mitigate (D)DoS attacks and to help hiding the IP address for the VM from script kiddies.

It’s not that I think Userrepository will ever be a target for a (D)DoS attack, but better safe than sorry. Also, I have more than enough automated failed SSH authentication attempts without revealing the IP: 441 blocked IPs and counting for one fail2ban ssh rule and 2 for another fail2ban ssh rule. I intend to tighten these rules in the near future.

A third (lesser) reason is their analytics. This allows me to evaluate, from time to time, if the repository is of interest for Arch and Arch-based Linux distribution users.

Although the analytics part is not the best-in-breed, it lets me take a look at the stats for the last 30 days. For example, in this time frame, at the time of writing of this blog post, I had 1486 unique visitors and 17622 total requests to userrepository.eu. I honestly expected around half that number at best.

Most of these unique visitors (and hopefully users), from first to last, come from France, Germany, Italy and USA. My country, Portugal, still hasn’t reached the 500 unique requests.

In terms of bandwidth statistics, the numbers are low: 10.14GB in the last 30 days, with only 878.35kB of cached content. This is expected because I doubt they would cache compressed files, but they’re probably caching the 01-README.txt file with the instructions to add the repository to your /etc/pacman.conf file.

The numbers, I must admit, are not what I wanted but they are more than I expected and that’s a strong motivation to keep the project running, hoping it will help other users.

One last thing: please become a Patron if you want to support userrepository.eu. Even €1 will help cover the monthly expenses, just over €15. If I get enough patrons, I’ll be able to upgrade the virtual machine to one with better specs, which will allow a higher package compression level, shorter build times and maybe even packaged kernels. Thank you!