HN user

snassar

161 karma

https://github.com/snassar

Posts3
Comments49
View on HN

I don't know how it is in other countries. We recently wondered what the right thing to do is and the Citystate of Berlin has an FAQ on recycling: https://www.bsr.de/die-top-13-mullmythen-26874.php which makes some things explicit:

(It is in German, but deepl translated the relevant section)

Do empty bottles and packaging have to be washed out?

No. Because the packaging is rinsed out in the recycling process, when the sorted plastics are shredded. It is only important that all packaging is emptied of residues [ed. The translation misses tmthat they mean large residue or levtover amounts], is not stacked and the lid is removed.

Where do you have this information from? The State of Berlin says otherwise https://service.berlin.de/dienstleistung/121864/en/ :

------ Sufficient knowledge of German You must have an adequate command of the German language (level B 1 of the Common European Framework of Reference for Languages).

If you were in possession of either a residence permit or a residence authorisation on 31/12/2004, you only have to demonstrate basic knowledge of the German language (level A 1) to be granted a permanent settlement permit. ------

In practice the staff giving interviewing you have leeway to assess your German level on the spot, but applying without demonstrated adequate German levels could lead to wasting ones time.

In Germany you have a probationary period of 6 months where both sides can give notice of 2 weeks without having to give a reason. The probationary period is really there to make sure that you fit the organization and that the organization fits you.

It is not usual that people don't make it through the probationary period, but it happens. If you know 5 months into a job that it is not for you and won't work out, then search for something that does. When asked why the time at X was so short, tell the hiring manager why. A place that dings you based on your honest assessment is not a place where you will want to work anyway.

The better solution to these kind of problems is having a backup concept with an implementation and regular testing of backups.

The encryption exposed a problem with your disks or system in general. Depending on what the problem was, the problem is still there but you are not seeing it. Now you have a possible problem and unencrypted files.

In practice you can use all three versions of GnuPG on three different devices without a particular difference. One problem you might see is if you are using the newer experimental curve-based algorithms on a computer running GnuPG 1.4 and you get blocked, but you really ought not to do that anyway.

As for the downgrading issue:

It used to be you could just copy your .gnupg directory from computer to computer to computer and that's what constituted migrating your PGP keys.

This was also true for moving frmo GnuPG 1.4 to GnuPG 2.x. If you are starting with a new GnuPG keystore from 2.1 you can't just copy .gnupg and use it in a GnuPG 1.4 system, you have to export your public keys, your private keys, and your trustdb (although I am iffy on what this does) and import them on the systems where you are running GnuPG 1.4 or 2.0

I am unaware of any 3rd party software directly accessing the GnuPG keystore, but that doesn't say much.

I don't know where people would run three versions at the same time. The information from the GnuPG project is clear: You can run GnuPG 1.x and GnuPG 2.x at the same time, but you should not have GnuPG 2.0 and GnuPG 2.1 installed at the same time, as bad things might happen.

What 3rd party software is using the keystorage mechanisms directly? Do you mean how information is output from GnuPG?

It sounds like the situation you are describing is the keystore, which has changed formats. GnuPG 2.1, as far as I can remember, will oll use the older versions keystore, but you are correct, once you have a 2.1 keystore it can't be used by GnuPG 2.0 and 1.x.

It's a tough call for the GnuPG developers and something distributions should help with. On one hand there is immense pressure to improve GnuPG, on the other hand, you have many actors who kick GnuPG around when it makes any deviation.

I would say defaulting to GnuPG 1.x is a bug and new releases of Linux, Homebrew, etc., should use GnuPG 2.0 at the very least, but better yet, use GnuPG 2.1 which has many of the things that people complain about fixed or in process of being fixed.

I don't really get what keybase.io is supposed to solve, but it doesn't get in the way of importing keys into Enigmail.

If you are in Enigmail's Keymanager you can import from a URL when the content is well-formatted.

Examples that work:

https://keybase.io/snassar/key.asc https://pgp.samirnassar.com http://keys.gnupg.net/pks/lookup?op=get&search=0x69A75542488...

It would be nice if Keybase made the URL more easily "gettable" instead of hiding it behind 2 clicks.

Getting a copy of "The Debian Administrator's Handbook" also helps support Raphaël Hertzog and Roland Mas keep doing good work.

I purchased a recent copy of the book (covering Debian 8), and while there are things I'd like more details about, I find it a good resource to have on hand.

Some ideas for useful addons to existing projects, keeping in mind I am not sure what your focus as a front-end developer is:

Gnu Privacy Assistant https://www.gnupg.org/related_software/gpa/index.html is a GnuPG frontend written in GTK. The software works well and does nice things like file encryption, taking a piece of text and outputting it encrypted.

The GUI badly needs improvement. I'd be happy to point out several problems. I also don't believe GPA is available in platforms like Windows and macOS.

Kleopatra is a GnuPG and S/MIME frontend written in Qt (KDE libraries). It is maintained and available on Windows (through GPG4Win) but is still "computer power user"-centric and could also use user interaction love.

Enigmail https://www.enigmail.net/index.php/en/ - Also has several pain points that might be interesting to solve.

On a side note: One method that Enigmail uses to import PGP certificate is the ability to get a valid PGP certificate from a URL. Adding that functionality to GPA and Kleopatra would be nice wins.

All three frontends, Enigmail, Kleopatra, or GnuPG would do well to have a graphical or screen-based export of public keys. Something like a QR-code export of a minimal PGP public key would be nice for importing via smartphones.

You are welcome. I tried finding a way to contact you from the medium article that didn't require signing up to or signing into something. I gave up after trying to comment on the article directly and only finding Twitter and Facebook links.

I'm about to update some tutorials that depend on GnuPG working on 64bit Windows and was worried that I'd need to modify my plans. Your particle made me take another look at the documentation and to re-check some assumptions. Thank you.

While there are pain points when it comes to hosting your own mail, it isn't nearly as difficult as you make it.

It gets more difficult if you are providing a service that has to have uptime guarantees or are providing mail to many users but if you take the time to learn and educate yourself on current standards, hosting your own mail for fun and for profit is a doable thing that more developers and admins should do.

We are at a time when we actually have relatively easy to use software to managing mail servers, so us it.

For what it is worth, I have not had problems with Google, Microsoft, Yahoo, or domains that use their services whether it comes to sending or receiving. Sometimes a server is stuck in an SPAM prevention queue or I might have to whitelist a particularly silly server, but that doesn't happen very often.

KatieConf 10 years ago

While I wouldn't have traveled to Australia for this, I find the concept of an idiosyncratic conference like this very cool conceptually in addition to supporting the political statement.

EDIT: I initially wrote Canada instead of Australia. Not that this changes the sentiment. Thanks for catching the error tedmiston.

In a court of law we should all be innocent until proven guilty. Outside of court if I behave like an asshole you have the right to not hang out with me or even suffer my presense. In fact, you even have the right to say: snassar is an asshole and I won't hang out on Hacker News if you tolerate him. It's up to the rest of Hacker News to decide if you are right or not.

Cool. Nice to have in contrast.

My personal feeling is this: systemd might be a software blackhole that eventually eat and destroy everything it comes close to and that's OK. If it is so bad then other developers can create a new or modified system that keeps the good stuff and eliminates the bad stuff, while working with other software projects to integrate better.

If we're stuck with systemd, is is better than others worse than some and it isn't like it is the first highly opinionated software project to grace us. A new ecosystem will get developed, wikis written, books sold, training courses packaged. Wise developers of other software will whisper in dark corners about the evil that stalks the land in the form of bad code and design of systemd, and crazed developers will haunt Slashdot, Hacker News, and LWN holding up the hand-lettered signs to make sure we understand how terrible Lennartitis is.

If something new comes along (more modular! less Lennart! doesn't insult the tender heart of tmux developers) developers will fight it out and we can go back to the 5 init systems that we're currently using.

This might or might not be true. I would be inclined to agree more with it if the evidence from other distribution highlighted this argument.

I don't see Debian or Arch developers making that argument.

Are they hiding how much pressure from Red Hat they feel? Unlikely. Linux developers are happy to blog, tweet, and post to mailing lists about large and small things, but somehow a concerted push by a corporation makes them fall silent and accept SystemD?

Inside Palantir 10 years ago

Signal has a nicer communication user interface for some communication compared to email + PGP but it has not really solved the verification problem that many secure communication methods have.

The grandparent is advising the writer to improve the verification aspects that PGP provides.

Have you tried re-establishing trust with a Signal user who wiped their device? It falls back to the same PGP problem of comparing a string of numbers over a different secure channel.

Moxie addresses some problems with the OpenPGP RFC and with the GnuPG implementation, but after re-reading that post I don't see how it relates to the verifiability issue the grandparent is bringing up.