snassar
(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.
------ 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.
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 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.
firefox -P <profilename>
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.
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.
With GnuPG 2.1 listing of keys shows the fingerprint.
I still do not know what problem keybase.io solves when they allow uploading of private keys.
Things to know about keyservers such as SKS: There is no way to remove keys or a way to really delete information. Uploading to know server will propagate that information to all SKS servers in the network over time.
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.
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.
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.
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.
He writes: If you’re using 64-bit Windows, don’t try to install GPG directly from the GPG website . It’s not supported. Gpg4win works just fine.
The page he sites: https://www.gnupg.org/download/supported_systems.html says:
NB: The information in this page is heavily outdated. GnuPG works very well on almost all 32 and 64 bit platforms.
For a moment I was torn between being proud in my passphrase and sad at my lack of friends.
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.
EDIT: I initially wrote Canada instead of Australia. Not that this changes the sentiment. Thanks for catching the error tedmiston.
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.
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?
Here is one answer from an Arch developer about why they adopted systemd:
https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...
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.
(I did open an issue about this.)