Hackeriet 10 years

20/02/20 — hackeriet

hackeriet 10 years

Hackeriet turned 10 years old last December! Time flies when you’re busy hacking! To mark this momentous occasion we decided to invite some old friends and new acquaintances to speak at Hackeriet on March 14th (also known as Pi day, a mathematically fortuitous date)!

Program

15:00: A short introduction to Internet Governance by Maja Enes

The term «Internet Governance» is an expression to define all actors and agencies who govern the Internet. But who are they, and what is this governing power they claim to hold? This session gives a short introduction to the term «Internet Governance», and looks closer at some of the more prominent bodies to see who are involved and how they work, and is it possible for you or me to make an actual difference?

Maja Enes has a background in Psychology and social work. She published the book «Internett Internett Internett» in 2019, to give people without a technical background the opportunity to be able to learn how Internet infrastructure works. This book was born out of the frustration Maja struggled with when she, as a newly appointed chair of the Norwegian Chapter of the Internet Society, tried to learn how Internet works. The last 5 years she has been working freelance and writes about things she does at www.frkenes.no, for example has she written about when she held a small soldering course at Hackeriet in 2015.

Sign up for this talk.

16:00: Introduction to election security by Patricia Aas

Free and correct elections are the linchpin of democracy. For a government to be formed based the will of the people, the will of the people must be heard. Across the world election systems are being classified as critical infrastructure, and they face the same concerns as all other fundamental systems in society.

We are building our critical infrastructure from hardware and software built by nations and companies we can’t expect to trust. How can this be dealt with in Election Security, and can those lessons be applied to other critical systems society depends on today?

Patricia Aas is a programmer who has worked mostly in C++ and Java. She has spent her career continuously delivering from the same code-base to a large user base. She has worked on two browsers (Opera and Vivaldi), worked as a Java consultant and on embedded telepresence endpoints for Cisco. She is focused on the maintainability and flexibility of software architecture, and how to extend it to provide cutting edge user experiences. Her focus on the end user has led her work more and more toward privacy and security, and she has recently started her own company, TurtleSec, hoping to contribute positively to the infosec and C++ communities. She is also involved in the Include C++ organization hoping to improve diversity and inclusion in the C++ community.

Sign up for this talk.

17:00: Dark Patterns and the GDPR by Quirin Weinzierl

Have you ever felt a website tricked you into providing your data? If so, you probably encountered a “Dark Pattern”. Service providers use tricks like defaults, countdowns and confusing language to get us to consent against our own interest. Understanding these patterns leads us into exploring how our decisions are shaped by psychological deficiencies, biases and rules of thumb.

The bad news: The General Data Protection Regulation (GDPR) is currently unable to stop Dark Patterns.

The good news: It could, if we use it the right way. And we all can help to confront Dark Patterns. In this talk we’ll get an idea of how both these things can work.

Quirin Weinzierl is a Ph.D. Candidate at University Speyer. He is currently a visiting Ph.D. researcher at the NRCCL/SERI, University of Oslo. At the German Research Institute for Public Administration Speyer Quirin serves as the coordinator of the research cluster “Transformation of the State in the Age of Digitalization”. Quirin studied law at University Munich and Yale Law School. He clerked at the European Court of Human Rights and worked at the German Parliament’s Academic Research Service. He searches for good behaviorally informed regulation and even better randonée-skiing in Norway.

Sign up for this talk.

18:00: Interactive serial communication by Øyvind Kolås

Øyvind Kolås will tell us about his experiences writing his own ANSI/ECMA-48/vt100 engine, and how he (via some dev-fuzzing) stumbled upon this bug

This talk on interactive serial communications might touch upon some of the following terms: baud, baudot, ascii, cp850, latin1, unicode, DEC, rs232, vt100, ANSI/ECMA-48, ansi.sys, telix, RIP, ReGIS, sixels, BBS, terminal emulator, tty, ssh/telnet NAWS, ascii-art, ansi-art, aalib, caca, chafa, tv. If any of this peaks your interest, come on down!

Øyvind Kolås is a digital media toolsmith, creating tools and infrastructure to aid creation of his own and others artistic and visual digital media experiments. He is the maintainer and lead developer of GIMPs next generations engine, babl/GEGL - infrastructure libraries where he for the more than the last decade have been working actively on providing high bitdepths, HDR, CMYK and non-destructive editing and capabilities/possibilities to GIMP - and other software. You can read more about Øyvind on his Patreon page.

Sign up for this talk.

19:00: The birthday gathering will continue until morale improves.

Here’s to another 0x00001010 years!


Questions? Chat with us on IRC at #oslohackerspace @ Freenode.

Welcome to Oslo NixOS MiniCon 2020!

29/01/20 — fnords && sgo

oslo-nixos-minicon

Saturday 22 Feb, and Sunday 23 Feb at Hackeriet in Oslo. This event is community organized and free.

Oslo NixOS User Group is very excited to invite you to our first 2 day mini conference. We’ve invited some great speakers to cover different aspects of the Nix ecosystem.

Saturday is dedicated to talks on NixOS, NixOps and the Nix language (and pizza for the ones who stick around to the end!). On Sunday we have a talk on how to build Docker containers with Nix, and we’ll end the day with a hands on Nix package workshop.

Please tell us that you’re coming by RSVPing on meetup.com:

SCHEDULE , DAY 1

  • 15:00: “The Nix Ecosystem” - by Elis Hirwing (etu)

    This presentation aims to give a brief overview of what Nix is, how it functions and some of its potential uses. Then we will look at NixOS and some other tools that is part of what makes the Nix ecosystem great!

  • 15:30: “NixOps” - by Kim Lindberger

    NixOps is a declarative and fully automated deployment system for NixOS. If you’ve been using NixOS as your desktop OS and would like it to be your server OS, or have been playing around with the Amazon AWS images and wonder what the next step is, this talk is for you.

  • 16:00: “Reading Nix expressions” - by Adam Höse (Adisbladis)

    You just installed Nix or NixOS. You have have a configuration.nix, default.nix or shell.nix and it just looks like a soup of characters? This talk is for you. Nix is not a big language but the syntax is quite foreign to the usual language suspects. The goal of this talk is to demystify the language. At the end all the viewers should be able to read Nix code and start wielding Nix’s super powers.

  • 17:00 until late: Let’s eat pizza and hang out! 🍕

SCHEDULE, DAY 2

  • 13:00: “Building Docker containers with Nix” - by Adam Höse (Adisbladis)

    So you’ve learnt how to build a Nix package and everything is great. Now we need to learn how to ship our packages to production, which nowadays often means deploying to a container registry and then running inside of Docker and/or Kubernetes.

    This talk will teach you not only how to build seamlessly integrated containers using Nix that brings reproducibility and traceability benefits of Nix, but also the inner workings of the Nixpkgs dockerTools functions. Hopefully we’ll also break a few peoples mental model of how Docker actually works under the hood.

  • 14:00 until late: Nix package workshop

    Do you have some software you want to package for Nix? Bring your laptop and your questions, we will try our best to help you!


Questions? Chat with us on IRC at #oslohackerspace @ Freenode.

Cover Photo Credit: Michael Ankes

Release of Ripasso version 0.4.0

26/01/20 — capitol

ripasso-cursive

After two months of development effort, we are proud to present ripasso version 0.4.0.

New Features

Support for localization

Ripasso’s ncurses based application now have support for localization and have been translated into:

  • French
  • Italian
  • Norwegian bokmål
  • Norwegian nynorsk
  • Swedish

Display a padlock icon if the git commit a password comes from have been signed by a valid key

If the git commit that a password came from have been signed by a gpg key that’s in your keyring, then ripasso will display a padlock icon ( 🔒 ) to symbolize this.

If there is a minor problem with the key, then an open padlock icon ( 🔓 ) will be displayed.

And if there was a major problem, then a stop icon ( ⛔ ) will be displayed.

Package for fedora created

Ripasso have now been packaged for fedora by Artem Polishchuk

Major startup time improvement

In the previous versions, ripasso did the equivalence of a git blame on every password file in the repository, this was fine for small repositories, but for large ones it didn’t work at all. The startup cost was on the order of O(n2) where n was the number of passwords.

This have been replaced by walking through the history once and populating the metadata for each file as we see them in the history.

Support for environmental variable PASSWORD_STORE_SIGNING_KEY

If you specify one or more 40 character gpg key ids in this variable, this ripasso will verify that the .gpg-id file in the password directory has been signed by one of those keys.

The signature is a detached gpg signature located in the .gpg-id.sig file.

Bugs Fixed

Don’t print passwords onscreen as they are generated

The generate button now prints stars instead of the actual password when pressed.

Prevent directory traversal

Before it was possible to create files outside the password store directory, by writing .. in the password path.

Credits

  • Joakim Lundborg - Developer
  • Alexander Kjäll - Developer
  • Artem Polishchuk - Fedora packager
  • Silje Enge Kristensen - Norwegian bokmål translation
  • Eivind Syvertsen - Norwegian nynorsk translation
  • Enrico Razzetti - Italian translation
  • Camille Victor Prunier - French translation

Also a big thanks to everyone who contributed with bug reports and patches.

Packaging a Rust project for Debian

25/01/20 — capitol

rust-landscape

I have started to package rust things for Debian, and the process have been pretty smooth so far, but it was very hard finding information on how to start, so here is a small writeup on how I packaged my first rust crate for Debian.

This was a totally uncomplicated crate without anything special in it.

1) Add my name and email to .bashrc

DEBEMAIL="my.email@example.com"
DEBFULLNAME="First-name Last-name"
export DEBEMAIL DEBFULLNAME

2) git clone https://salsa.debian.org/rust-team/debcargo-conf.git

All Debian’s rust package information lives in one big repository on salsa.debian.org.

3) cd debcargo-conf

4) ./update.sh crate-name

This is the script that does most of the work, it looks at the crate named crate-name on crates.io and pre-populates what it can in the files in the src/crate-name/debian/ directory.

5) cd src/crate-name/debian/

The Debian directory is where all the meta information that Debian needs about a package lives.

6) cp copyright.debcargo.hint copyright

The update.sh script tries to obtain the correct copyright information, but it guesses a lot and often needs to be touched up afterwards. The original guess work is in copyright.debcargo.hint and should not be modified, but committed as is.

7) Fix copyright

After copying the original guess we need to go over it and fix the things it didn’t manage to generate correctly.

Common things to fix is:

  • The years that the work was produced in, as this information isn’t in the crate. I normally look at the git repository and take the years for the first and last commit.
  • Copyright for the license files, it often singles out the license files and have those as separate sections. It’s unclear if the license text is under copyright, most likely not, and it should just be deleted from the file.
  • Add license text. It the crate only refers to a license, without including the text in a license file, and it’s not one of Debian’s well known licenses, then it needs to be added manually.

8) Add dependencies to native packages like this in debcargo.toml

If your rust code depends on a native library, then you need to tell specify the name of that Debian package.

[packages.lib]
depends = ["libyaml-dev"]

9) Setup a repeatable build env.

We need to test that the crate can be built without problems, and for that we need a build environment.

sudo apt install devscripts reprepro debootstrap sbuild dh-cargo
sudo sbuild-createchroot --include=eatmydata,ccache,gnupg,dh-cargo,cargo,lintian,perl-openssl-defaults \
      --chroot-prefix debcargo-unstable unstable \
      /srv/chroot/debcargo-unstable-amd64-sbuild http://deb.debian.org/debian

10) cd ../../../build && ./build.sh crate-name

This performs a test build of the crate, and runs the lintian tool in order to detect common mistakes.

These two lintian failures always happens with new crates, and can be ignored:

E: rust-gpgme-sys changes: bad-distribution-in-changes-file UNRELEASED-FIXME-AUTOGENERATED-DEBCARGO
W: librust-gpgme-sys-dev: new-package-should-close-itp-bug

11) Add RFS file

When everything builds and lintian doesn’t complain, then it’s time to ask a Debian maintainer to upload the package to Debian. This is done by adding a file named RFS to the Debian directory.

touch ../src/crate-name/debian/RFS

12) Add everything to a branch

cd ..
git branch package-crate-name
git checkout package-crate-name
git add .
git commit -m "package version X.Y.Z of crate-name"

13) git push git@salsa.debian.org:capitol-guest/debcargo-conf.git

Push your branch to your fork of the debcargo-conf project, and create a pull request from it.

14) Join #debian-rust on irc.oftc.net on irc

The people in the channel was really helpful and answered all my stupid questions about how the process works when I tried to learn it.

Release of Ripasso version 0.3.0

01/12/19 — capitol

ripasso-cursive

We have just released version 0.3.0 of Ripasso, a password manager that lets you control the level of risk that you expose your passwords to.

New Features

Support for signing Git commits, if it’s configured in Git’s config

If you set the Git configuration values commit.gpgsign and user.signingkey, then Ripasso will respect them when creating Git commits and signing those.

Display who touched a password last

If the password store is backed by a Git repository, then Ripasso will read and display who changed a password last.

Support for initializing a Git repo in the quick start wizard

If you start Ripasso without a password store directory you will get a guide that helps you get set up. That guide now also gives you the opportunity to initialize a Git repository.

Added a status bar, and a menu

We reworked to information at the bottom of the screen, moved the shortcuts into a menu and added a status bar that displays what’s happening in the application.

Bugs Fixed

Made Ctrl-W behave as in the shell, so that you can delete last typed word with it.

Fixed performance problem if the Git repo was large

Ripasso initialized the Git repository once for every operation that it did, which was very slow. Ownership of the Git repository object have now been moved so that it will only be initialized once.

Fixed problem with passwords that contained a . character

Newly created passwords that contained a . character weren’t accessible without a restart.

Install Instructions

Arch Linux

Arch now has two packages, ripasso-git that tracks the development branch and ripasso-cursive that contains the stable version.

yay install ripasso-git

or

yay install ripasso-cursive

Nix

nix-env -iA nixpkgs.ripasso-cursive

General

git clone git@github.com:cortex/ripasso.git
cd ripasso
cargo build -p ripasso-cursive

Credits

  • Joakim Lundborg - developer
  • Alexander Kjäll - developer
  • Stig Palmquist - NixOS packager
  • Tae Sandoval - NixOS macos packager
  • David Plassman - Arch packager

Also a big thanks to everyone who contributed with bug reports and patches.