The InterPlanetary File System (IPFS) can be used to provide files in a more efficient and distributed way than HTTP.

Our filesystem repo already has the go-ipfs client.

You use it with
ipfs daemon --init

And then you can add my Tumbleweed mirror with
zypper ar http://127.0.0.1:8080/ipns/opensuse.zq1.de./tumbleweed/repo/oss/ ipfs-oss

You can also browse the content online at
http://opensuse.zq1.de./tumbleweed/repo/oss/ . During my testing I found that the results are sometimes inappropriately cached on the Cloudflare CDN, so if you used it under this URL without the ipfs client, this might throw signature errors in zypper.

On the server side, the mirror is updated using the syncopensuse script from
https://github.com/bmwiedemann/opensusearchive and consistency of the repo is verified with checkrepo

When a complete repo was synced, dynaname updates a DNS entry to point to the new head:

> host -t txt _dnslink.opensuse.zq1.de.
_dnslink.opensuse.zq1.de is an alias for tumbleweedipfs.d.zq1.de.
tumbleweedipfs.d.zq1.de descriptive text “Last update: 2019-04-03 12:23:43 UTC”
tumbleweedipfs.d.zq1.de descriptive text “dnslink=/ipfs/QmSXEVuU5z23rDxMyFYDhSAUaGRUPswuSXD3aVsBEzucjE”

If you got spare bandwidth and 300 GB disk on some public server, you could also host a mirror of today’s version, simply by doing ipfs pin add QmSXEVuU5z23rDxMyFYDhSAUaGRUPswuSXD3aVsBEzucjE

This is a permalink: http://127.0.0.1:8080/ipfs/QmSXEVuU5z23rDxMyFYDhSAUaGRUPswuSXD3aVsBEzucjE also browsable via any public IPFS gateway. This means, it will always remain on the 20190401 version of Tumbleweed and no changes in content are possible – similar to how a git commit ID always refers to the same data.

So why did I create this IPFS mirror? That is related to my work on reproducible builds for openSUSE. There it regularly happened that published Tumbleweed binaries were built with libraries, compilers and toolchains that were no longer available in current Tumbleweed. This prevented me from verifying that the published binaries were indeed built correctly without manipulation on the OBS build workers.

Now, with this archive of rpms easily available, it was possible to verify many more Tumbleweed packages than before. And most importantly, it remains possible to independently verify even after Tumbleweed moves on to newer versions. This data is going to stay available as long as anyone pins it on a reachable server. I’m going to pin it as long as it remains relevant to me, so probably a bit until after the next full Tumbleweed rebuild – maybe 6 to 12 months.

Thus, it now is even less easy to sneak in binary backdoors during our package build process.

For ergonomic reasons, I’ve long used Trackballs as pointing devices instead of regular mice. For several years now, I have been using a Logitech Trackman Marble and a libinput tweak to use the trackball for scrolling by holding down one of the buttons while spinning the ball.

This worked well until some distributions decided to switch to using Wayland as a replacement for X.org. In the past, I have been reverting back to using X.org (by setting WaylandEnable=True in /etc/gdm/custom.conf), as Wayland does not support the required libinput configurations. I found a workaround that creates a shared library that can be preloaded to implement this, but that looked somewhat hacky to me.

But as Wayland seems to be the way forward and my latest distribution upgrade caused some weird X.org issues (my dual-screen setup did no longer work properly), I caved in and switched to Wayland again. At least all of my screens were properly detected afterward, but the scroll wheel emulation was broken. I did some research to see if the libinput support in Wayland had improved in that regard in the meanwhile, but it seems it doesn’t.

However, I found a solution for enabling mouse wheel emulation in Wayland/GNOME3 on the Arch Linux Wiki: simply run the following command in a terminal window:

gsettings set org.gnome.desktop.peripherals.trackball scroll-wheel-emulation-button 8

Now button 8 (the small button above the left button) acts both as a “back” button (e.g., when browsing web pages) as well as the modifier that turns the trackball into a scroll wheel, just like before. Nifty!

The translation-finder module has been released in version 1.1. It is used by Weblate to detect translatable files in the repository making setup of translation components in Weblate much easier. This release brings lot of improvements based on feedback from our users, making the detection more reliable and accurate.

Full list of changes:

• Improved detection of translation with full language code.
• Improved detection of language code in directory and file name.
• Improved detection of language code separated by full stop.
• Added detection for app store metadata files.
• Added detection for JSON files.
• Ignore symlinks during discovery.
• Improved detection of matching pot files in several corner cases.
• Improved detection of monolingual Gettext.

Filed under: Debian English SUSE Weblate

Password managers are all the rage these days, I guess… I haven’t ever been compelled to try as the password manager I have been using, my shoddy memory, has been working alright for me. The reality is, I have a lot more passwords to remember now and for those passwords I don’t use as frequently, … Continue reading Bitwarden a Secure Password Manager on openSUSE →

After the librsvg team finished the rustification of librsvg's main library, I wanted to start porting the high-level test suite to Rust. This is mainly to be able to run tests in parallel, which cargo test does automatically in order to reduce test times. However, this meant that librsvg needed a Rust API that would exercise the same code paths as the C entry points.

At the same time, I wanted the Rust API to make it impossible to misuse the library. From the viewpoint of the C API, an RsvgHandle has different stages:

• Just initialized
• Loading
• Loaded, or in an error state after a failed load
• Ready to render

To ensure consistency, the public API checks that you cannot render an RsvgHandle that is not completely loaded yet, or one that resulted in a loading error. But wouldn't it be nice if it were impossible to call the API functions in the wrong order?

This is exactly what the Rust API does. There is a Loader, to which you give a filename or a stream, and it will return a fully-loaded SvgHandle or an error. Then, you can only create a CairoRenderer if you have an SvgHandle.

For historical reasons, the C API in librsvg is not perfectly consistent. For example, some functions which return an error will actually return a proper GError, but some others will just return a gboolean with no further explanation of what went wrong. In contrast, all the Rust API functions that can fail will actually return a Result, and the error case will have a meaningful error value. In the Rust API, there is no "wrong order" in which the various API functions and methods can be called; it tries to do the whole "make invalid states unrepresentable".

To implement the Rust API, I had to do some refactoring of the internals that hook to the public entry points. This made me realize that librsvg could be a lot easier to use. The C API has always forced you to call it in this fashion:

1. Ask the SVG for its dimensions, or how big it is.
2. Based on that, scale your Cairo context to the size you actually want.
3. Render the SVG to that context's current transformation matrix.

But first, (1) gives you inadequate information because rsvg_handle_get_dimensions() returns a structure with int fields for the width and height. The API is similar to gdk-pixbuf's in that it always wants to think in whole pixels. However, an SVG is not necessarily integer-sized.

Then, (2) forces you to calculate some geometry in almost all cases, as most apps want to render SVG content scaled proportionally to a certain size. This is not hard to do, but it's an inconvenience.

SVG dimensions

Let's look at (1) again. The question, "how big is the SVG" is a bit meaningless when we consider that SVGs can be scaled to any size; that's the whole point of them!

When you ask RsvgHandle how big it is, in reality it should look at you and whisper in your ear, "how big do you want it to be?".

And that's the thing. The HTML/CSS/SVG model is that one embeds content into viewports of a given size. The software is responsible for scaling the content to fit into that viewport.

In the end, what we want is a rendering function that takes a Cairo context and a Rectangle for a viewport, and that's it. The function should take care of fitting the SVG's contents within that viewport.

There is now an open bug about exactly this sort of API. In the end, programs should just have to load their SVG handle, and directly ask it to render at whatever size they need, instead of doing the size computations by hand.

When will this be available?

I'm in the middle of a rather large refactor to make this viewport concept really work. So far this involves:

• Defining APIs that take a viewport.

• Refactoring all the geometry computation to support the semantics of the C API, plus the new with_viewport semantics.

• Fixing the code that kept track of an internal offset for all temporary images.

• Refactoring all the code that mucks around with the Cairo context's affine transformation matrix, which is a big mutable mess.

• Tests, examples, documentation.

I want to make the Rust API available for the 2.46 release, which is hopefully not too far off. It should be ready for the next GNOME release. In the meantime, you can check out the open bugs for the 2.46.0 milestone. Help is appreciated; the deadline for the first 3.33 tarballs is approximately one month from now!

Weblate 3.5.1 has been released today. Compared to the 3.5 release it brings several bug fixes and performance improvements.

Full list of changes:

• Fixed Celery systemd unit example.
• Fixed notifications from http repositories with login.
• Fixed race condition in editing source string for monolingual translations.
• Include output of failed addon execution in the logs.
• Improved validation of choices for adding new language.
• Allow to edit file format in component settings.
• Update installation instructions to prefer Python 3.
• Performance and consistency improvements for loading translations.
• Make Microsoft Terminology service compatible with current zeep releases.
• Localization updates.

If you are upgrading from older version, please follow our upgrading instructions.

You can find more information about Weblate on https://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Turris, FreedomBox, Weblate itself and many other projects.

Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure.

Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: Debian English SUSE Weblate

We are creating a deployment of openSUSE clients with Salt. Kerberos needs password authentication. Therefore, we want to encrypt passwords before using them in Salt. I want to explain how to integrate that all.

At first, you have to install gpg, python-gnupg and python-pip. openSUSE wants to install only the package python-python-gnupg which isn’t enough for Salt. You have to use additionally pip install python-gpg.

After that, you have to create the directory /etc/salt/gpgkeys with mkdir. That will be the home directory for the decryption key of Salt. Then you can create a password less key in this directory. Salt is not able to enter any password for encryption.

# gpg --gen-key --pinentry-mode loopback --homedir /etc/salt/gpgkeys
gpg (GnuPG) 2.2.5; Copyright (C) 2018 Free Software Foundation, Inc.This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.

Note: Use "gpg2 --full-generate-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Salt-Master
Email address: sarahjulia.kriesch@th-nuernberg.de
You selected this USER-ID:"Salt-Master <sarahjulia.kriesch@th-nuernberg.de>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? O
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key B24D083B4A54DB47 marked as ultimately trusted
gpg: directory '/root/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/6632312B6E178E0031B9C8E8B24D083B4A54DB47.rev'
public and secret key created and signed.

pub   rsa2048 2019-02-05 [SC] [expires: 2021-02-04]
      6632312B6E178E0031B9C8E8B24D083B4A54DB47
uid   Salt-Master <sarahjulia.kriesch@th-nuernberg.de>
sub   rsa2048 2019-02-05 [E] [expires: 2021-02-04]

After that you have to export and import your public and secret key in an importable format. Salt can not decrypt passwords without the Secret Key.

# gpg --homedir /etc/salt/gpgkeys --export-secret-keys --armor > /etc/salt/gpgkeys/Salt-Master.key
# gpg --homedir /etc/salt/gpgkeys --armor --export > /etc/salt/gpgkeys/Salt-Master.gpg
# gpg --import Salt-Master.key
gpg: key 9BE990C7DBD19726: public key "Salt-Master <sarahjulia.kriesch@th-nuernberg.de>" imported
gpg: key 9BE990C7DBD19726: secret key imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1

# gpg --import salt-master.pub
gpg: key 9BE990C7DBD19726: "Salt-Master <sarahjulia.kriesch@th-nuernberg.de>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

The key has the validity unknown at the moment. We have to trust that. Therefore, we have to edit the key, trust that, enter a 5 for utimately and save that.

# gpg --key-edit Salt-Master
gpg (GnuPG) 2.2.5; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa2048/3580EA8183E8E03E
     created: 2019-02-05  expires: 2021-02-04  usage: SC
     trust: unknown       validity: unknown
ssb  rsa2048/4ABC9E975BD76370
     created: 2019-02-05  expires: 2021-02-04  usage: E
[ unknown] (1). Salt-Master <sarahjulia.kriesch@th-nuernberg.de>

gpg> trust
sec  rsa2048/3580EA8183E8E03E
     created: 2019-02-05  expires: 2021-02-04  usage: SC
     trust: unknown       validity: unknown
ssb  rsa2048/4ABC9E975BD76370
     created: 2019-02-05  expires: 2021-02-04  usage: E
[ unknown] (1). Salt-Master <sarahjulia.kriesch@th-nuernberg.de>

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y

sec  rsa2048/3580EA8183E8E03E
     created: 2019-03-07  expires: 2021-03-06  usage: SC
     trust: ultimate      validity: unknown
ssb  rsa2048/4ABC9E975BD76370
     created: 2019-03-07  expires: 2021-03-06  usage: E
[ unknown] (1). Salt-Master <sarahjulia.kriesch@th-nuernberg.de>
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> save

So the key is validity and usable. You can see your keys listed with following commands.

# gpg --list-keys
# gpg --homedir /etc/salt/gpgkeys --list-keys

Salt needs access to the key for decryption. Therefore, you have to change permissions on /etc/salt/gpgkeys.

# chmod 0700 /etc/salt/gpgkeys
# chown -R salt /etc/salt/gpgkeys

We can decrypt passwords with the key now. Replace supersecret with your password and Salt-Master with the name of the key.

# echo -n "supersecret" | gpg --armor --batch --trust-model always --encrypt -r "Salt-Master"
    -----BEGIN PGP MESSAGE-----

    hQEMA0q8npdb12NwAQf+IuJgOPMLdsfHR1hGRPPkUPWaw7kbmRyMDT0VdGzCupQr
    +biaeIF2vuCjUn3RyI0t/E8GcBKUcsc1z7Xy22jAXl5c0pQNj0X9iK4ebpP5sHWc
    vdnn6J2KIKMe5lRsgcVmnZ9/yBssarpLLsw8SiPu1XofVmMjzRjQFONa2gpBe/5q
    hb/dSccP2f2kbDZ0Up12ntjUReyImn9/TLOsLOlQzEH0OGcJJXqk0SKP/HoH5+jJ
    FDMEZYWDhUyLdSwsa7RVB8tgFSQW8EJnehc2oLExKZ+ngW5hJfHI3l8N4IWv92ow
    bSvZsVaH+h8epCOLgiYQsiWBJ/dWl1ZQx+tmHfAtT9JFAbk/gbeOfZ8RboX2JvRv
    h7semDNEYxqG8zusn8JykzivV37DERixR8nbh1XQDsOF5l0AmIrdJB6dvGW88tR+
    ei2ij0QM
    =rl1+
    -----END PGP MESSAGE-----

The output is a Base64 encoded PGP Message. You can use that in your sls file (in my case kerberos.sls) in the pillar directory.

kerberos:
  principal: X95A
  password: |
    -----BEGIN PGP MESSAGE-----

    hQEMA0q8npdb12NwAQf+IuJgOPMLdsfHR1hGRPPkUPWaw7kbmRyMDT0VdGzCupQr
    +biaeIF2vuCjUn3RyI0t/E8GcBKUcsc1z7Xy22jAXl5c0pQNj0X9iK4ebpP5sHWc
    vdnn6J2KIKMe5lRsgcVmnZ9/yBssarpLLsw8SiPu1XofVmMjzRjQFONa2gpBe/5q
    hb/dSccP2f2kbDZ0Up12ntjUReyImn9/TLOsLOlQzEH0OGcJJXqk0SKP/HoH5+jJ
    FDMEZYWDhUyLdSwsa7RVB8tgFSQW8EJnehc2oLExKZ+ngW5hJfHI3l8N4IWv92ow
    bSvZsVaH+h8epCOLgiYQsiWBJ/dWl1ZQx+tmHfAtT9JFAbk/gbeOfZ8RboX2JvRv
    h7semDNEYxqG8zusn8JykzivV37DERixR8nbh1XQDsOF5l0AmIrdJB6dvGW88tR+
    ei2ij0QM
    =rl1+
    -----END PGP MESSAGE-----

Salt is not able to distinguish encrypted from non-encrypted strings at the moment.

You have to uncomment the entry gpg_keydir: and add /etc/salt/gpgkeys in the salt-master configuration of /etc/salt/master. In addition, you can find the part with decrypt_pillar:. In my case, I add – ‚kerberos:password‘: gpg there.

You need a restart of the service salt-master. Afterwards Salt knows, that the special pillar entry has to be decrypted with gpg. Following you can run the sls file on any salt client and Salt can use the password.

At the end you should remove the command with your password for the PGP Message creation in your bash history. Therefore, edit ~/.bash_history and remove the entry with echo. So nobody can figure out the secure encrypted password for the user.

The post Password Security with GPG in Salt on openSUSE Leap 15.0 first appeared on Sarah Julia Kriesch.

I. Am. Back.

This is the crowbyte revival. Besides the brand new design there are lot more changes under the hood. If you are curious what, then ...

crowbyte is finally back

I know it has been a long time - a really very long long time - that my blog saw love and dedication from me. Sorry, my dear blog and sorry dear reader.

No promises about more content this time, which I might not be able to keep up to. So more time to focus on what has changed under the hood of crowbyte and about me...

Salient OS is the first Arch based distribution that I put any significant time into. Salient takes the heavy lifting out of Arch. The value of not building your own Arch system and using somebody else’s assembly can be debated but that is outside of the scope of this review. I am looking at this … Continue reading Salient OS | Review from an openSUSE User →