dnet

In newer versions, it's disabled by default and you have to do something like this to enable in ~/.ssh/config:

    Host *
    EnableEscapeCommandline yes

See https://doctorow.medium.com/como-is-infosec-307f87004563

> This is the same failure mode of all security-through-obscurity. Secrecy means that bad guys are privy to defects in systems, while the people who those systems are supposed to defend are in the dark, and can have their defenses weaponized against them.

I assume the scanner is a separate library/service that receives the contents and returns a boolean safe/malicious result, and the implementation using MD5 to avoid expensive re-scans is an internal detail hidden from the caller.

While the default is indeed to lock the entire database, it has been an option for 15 years to avoid this: https://www.sqlite.org/wal.html

> After several lawsuits and years of backlash Paypal has stopped seizing people's money illegally.

Flipper Zero project might disagree:

https://nitter.lacontrevoie.fr/flipper_zero/status/156719464...

https://www.dailydot.com/debug/flipper-zero-paypal/

I made my own CA for this because nothing else could provide transparency regarding certificate issuance (whether an attacker issued a "spare" backdoor certificate)

- source code: https://github.com/silentsignal/zsca

- my talk about the design and results: https://pretalx.hsbp.org/camppp7e5/talk/D3E9HN/

Why do you mention AVR? AVR-GCC has C++ support, that's what made the original Arduino (before they switched to ARM) approachable to beginners.

> I'm not even sure it's working in the EU yet?

It's called PSD2 and it applies EU-wide since September 2019. Banks have to make _some_ form of API available to third parties. However, these third parties must meet certain criteria and get a license in one of the member states. This makes sense since they can access financial data, and they only have to do it once. So a fintech licensed in e.g. Belgium can access the APIs of a bank in France and vice versa. Since banks already have most of the necessary rules and paperwork in place, I've seen many banks themselves become PSD2 clients as well, offering customers the ability to manage "foreign" bank accounts through their app as well.

Not sure about VLC, but ffmpeg has great support for Blackmagic, you just have to download the Blackmagic SDK, compile ffmpeg with Blackmagic support (and the SDK in path) and then you'll have a separate input/output device available in ffmpeg. The other great thing about this approach is that this way audio also takes a dedicated, integrated path, bypassing OS layers and maintaining sync with much less effort.

Erlang supports hot reloading by design with no limitations. There can even be some threads using the old and some using the new version simultaneously. It was designed for phone exchanges where they aimed for 9 nines of availability. You can install it on most mainstream operating systems.

Not necessarily -- there can be a number of reasons one can access localhost over the loopback interface that does _not_ imply root access: SSRF, misconfigured tunnels, or just a plain unpriviliged account where the attacker couldn't perform privilege escalation (either because the attacker's incompetence or the system being up-to-date and/or hardened)

Yet we've had people argue that they wouldn't give us the public part of their JWT RSA signing keypair, because "they wouldn't publish that anyway", hence this post.

Tresorit comes from Hungary, they just made a business entity in Switzerland to look better from security/privacy perspective. See https://en.wikipedia.org/wiki/Tresorit#History

Regular SSH won't work if your IP address changes since it uses TCP where sessions are tied to (IP address, port) tuples. However mosh uses UDP and its own session management scheme, so you can "roam" between IP addresses and your session will stay alive, you can continue typing and will receive screen updates as if nothing has happened.

That wouldn't work for HTTP(S) or anything else that works over TCP since the reply would go towards the fake source IP address, thus the attacker couldn't even get past the 3-way TCP handshake.

But those wouldn't take most of the world's public git repos down all at once just because of a single issue. Single points of failure have a bad reputation for a reason.

That's only relevant if you're using it to make signatures, thus you can make two inputs that hash to the same digest, and signing that digest creates a signature that's valid for both inputs.

In this case, the only threat model might be brute forcing the answer, but that applies to SHA-2 as well, since both are designed to be fast so that you can hash gigabytes in reasonable well. For that, something memory-hard such as Argon2 should be used.

You omitted an important part: the pointer pointing to the stack. In GC'd or refcounted languages, (almost) everything is on the heap (occasional exceptions being primitive types like integers). This of course leads to worse performance because of an additional dereferencing step and cache misses.

Using Elliptic Curve cryptography would've resulted in much smaller signatures, libsodium is considered secure and has bindings to most sane/modern environments: https://download.libsodium.org/doc/

JWT also has its fair share of security issues in itself: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

Removing leading zeroes doesn't require Python. One easy solution would be sed:

    $ echo -e '0001\n0010\n0002' | sed 's/^0*//'
    1
    10
    2

That's mostly irrelevant, since that only protects the integrity and confidentiality of that TCP connection. However, you can still exploit the vulnerabilities of all the services listening on the device. Separating voting machine networks from the internet is orthogonal to the problem of network protocol hardening between endpoints within this "separated" network.

Sure, the IPv6 address of my server (vsza.hu) is 2a01:270:2016::1, which is 2-A-0-1-colon-2-7-0-colon-2-0-1-6-double-colon-1 over the phone. Many people seem to forget that leading zeroes within 16-bit groups and one contiguous block of zeroes can be omitted.

One example are JSON/XML/HTML responses over HTTP: you need the 8-bit ("binary") data in an ASCII format to fit into JSON/XML/HTML, while HTTP provides gzip (or DEFLATE, Brotli, etc.) compression over the whole response if both the client (by including the "Accept-Encoding" header in the request) and the server implementations support it.

> both .png and .jpg are already compressed formats, with "better than gzip" strength

FWIW, PNG and gzip both use the DEFLATE algorithm, so I wouldn't call PNG's compression "better than gzip".

Source: https://en.wikipedia.org/wiki/DEFLATE

> This has led to its widespread use, for example in gzip compressed files, PNG image files and the ZIP file format for which Katz originally designed it.

It depends. I wrote a blogpost about the security implications of UUIDs back in February (https://blog.silentsignal.eu/2017/02/17/not-so-unique-snowfl...) and it shows that not all standard libraries make secure-by-default easy for the developer. I developed a MIT licensed plugin for Burp Suite (https://github.com/silentsignal/burp-uuid) that can help pentesters and security minded developers to detect insecure UUID versions, and even in that plugin I described version 4 UUIDs as "randomly generated, although [their] entropy should be checked".

IMHO it's because you learn your first language spoken first, written after -- and most people learn further languages after they learned writing, so they can learn to differentiate between words that sound similar/same.

I know little about most of them, since we did penetration testing (simulating what could an attacker over the 'net do) most of the time, as few of our clients have the budgets for a proper source code review. No CMSs were used, we had one Wordpress, but that was actually almost perfect, since they kept it up to date. These projects were custom-made business applications, not "dynamic" web sites.

Frameworks were sometimes used, although their effect on security is somewhat baffling at first sight -- and this is regardless of the platform, although we found most issues with PHP and J2EE. Sure, when you use the framework for security-critical things such as constructing SQL queries (SQLi) or HTML output (XSS), things work quite well. However, since most developers don't think about these issues, the single time they have to "escape" from the framework, since it doesn't (or they just think it doesn't) support a certain scenario, they don't know about all the things PHP and in smaller ways, J2EE requires to do for security.

Of course, this way, the framework protects 9x% of the application, but the asymmetry of security is that the attacker only needs a single vulnerability while the defender must patch it all.

My company does penetration testing and most of the projects involve web apps. Our clients use PHP, J2EE and .NET, and after 7 years of operation, we clearly see a trend where the number and severity of security issues are highest in PHP apps, lowest for .NET, with J2EE in the middle. Of course, there's the odd secure PHP app and the .NET project with gaping holes, but the trend is obvious.

So it's not peer pressure, we actually have data to back this up, and if you think about it, the whole thing boils down to motivation. Sure, you can write secure and insecure code as well in any language/environment. But defaults are powerful, and it makes me feel sad every time I have to write in reports that "you should've paid attention to opt-in to the secure solution every time you do X" vs. when we do demos to developers and we have to work really hard to disable every protection built into ASP.NET. (And no, I don't like Microsoft at all.)

Actually, Solt is not Middle East, but in Central Europe. (I live ~50 km from it.) But yes, it's 2 MW, and at night, it can be heard using conventional receivers as far as Belgium.