Same in Python, Rust, Haskell and probably many others.
But apparently JS does work that way, that is its filter
always iterates over everything and returns a new array and not some iterator object.
Same in Python, Rust, Haskell and probably many others.
But apparently JS does work that way, that is its filter
always iterates over everything and returns a new array and not some iterator object.
It seems OP wanted to pass the file name to -k
, but this parameter takes the password itself and not a filename:
-k password
The password to derive the key from. This is for compatibility with previous versions of OpenSSL. Superseded by the -pass argument.
So, as I understand, the password would be not the first line of /etc/ssl/private/etcBackup.key
, but the string /etc/ssl/private/etcBackup.key
itself. It seems that -kfile /etc/ssl/private/etcBackup.key
or -pass file:/etc/ssl/private/etcBackup.key
is what OP wanted to use.
I like btdu which is essentially ncdu, but works in a way that is useful even if advanced btrfs features (CoW, compression etc.) are used.
I am afraid you are still a bit misled; WireGuard is exactly what they use for the demo video. In general the underlying protocol does not matter, since the vulnerability is about telling the system to direct the packages to the attacker, completely bypassing the VPN.
I really need to try out Mercury one day. When we did a project in Prolog at uni, it felt cool, but also incredibly dynamic in a bad way. There were a few times when we misspelled some clause, which normally would be an error, but in our case it just meant falsehood. We then spent waaay to much time searching for these. I can’t help but think that Mercury would be as fun as Prolog, but less annoying.
I actually use from time to time the Bower email client, which is written in Mercury.
My understanding is that all issues are patched in the mentioned releases, the config flag is not needed for that.
The config flag has been added because supporting clients with different endianness is undertested and most people will never use it. So if it is going to generate vulnerabilities, it makes sense to be able to disable it easily, and to disable it by default on next major release. Indeed XWayland had it disabled by default already, so only the fourth issue (ProcRenderAddGlyphs
) is relevant there if that default is not changed.
I got curious and decided to check this out. This value was set to the current one in 2009: https://github.com/torvalds/linux/commit/341c87bf346f57748230628c5ad6ee69219250e8 The reasoning makes sense, but I guess is not really relevant to our situation, and according to the newest version of the comment 2^16 is not a hard limit anymore.
The bootloader is stored unencrypted on your disk. Therefore it is trivial to modify, the other person just needs to power down your PC, take the hard drive out, mount it on their own PC and modify stuff. This is the Evil Maid attack the other person talked about.
IANAL nor intelligent, but after skimming the text of the directive I felt like the definition of damage is very limited. In particular, if I understand correctly:
would not be covered by this directive, this directive is only about a human being hurt in some way,
would be covered in case of “your game installs a kernel-level anticheat and the anticheat breaks PCs”, but not in the case of “you uploaded an upgrade to a firmware of the washing machine you produced and it bricked the machines”; the directive is not about a product breaking, but about the product breaking your health, other property or data,
is basically the exact case this directive covers.