joepie91

Please don't include minified builds in your npm packages!

There's quite a few libraries on npm that not only include the regular build in their package, but also a minified build. While this may seem like a helpful addition to make the package more complete, it actually poses a real problem: it becomes very difficult to audit these libraries.

The problem

You've probably seen incidents like the event-stream incident, where a library was compromised in some way by an attacker. This sort of thing, also known as a "supply-chain attack", is starting to become more and more common - and it's something that developers need to protect themselves against.

One effective way to do so, is by auditing dependencies. Having at least a cursory look through every dependency in your dependency tree, to ensure that there's nothing sketchy in there. While it isn't going to be 100% perfect, it will detect most of these attacks - and no

chicoxyzzy

Russian WebAssembly Community

• telegram chat
• WebAssembly FAQ

Become a speaker

Please contact Sergey Rubanov (telegram, twitter), Mikhail Voronov (telegram) or Alexey Frolov (telegram)

philip-bl

# https://about.sourcegraph.com/blog/thyme-a-simple-cli-to-measure-human-time-and-focus/
# https://github.com/sourcegraph/thyme

[Unit]
Description=Call thyme to save windows usage to json for statistics

[Service]
Type=oneshot
ExecStart=/home/shibbiry/go/bin/thyme track -o /home/shibbiry/logs/thyme.json
# if thyme has not finished in 5 seconds, consider it failed and kill it

joepie91

A few notes on the "Gathering weak npm credentials" article

Yesterday, an article was released that describes how one person could obtain access to enough packages on npm to affect 52% of the package installations in the Node.js ecosystem. Unfortunately, this has brought about some comments from readers that completely miss the mark, and that draw away attention from the real issue behind all this.

To be very clear: This (security) issue was caused by 1) poor password management on the side of developers, 2) handing out unnecessary publish access to packages, and most of all 3) poor security on the side of the npm registry.

With that being said, let's address some of the common claims. This is going to be slightly ranty, because to be honest I'm rather disappointed that otherwise competent infosec people distract from the underlying causes like this. All that's going to do is prevent this from getting fixed in other l

joepie91

Not all random values are created equal - for security-related code, you need a specific kind of random value.

A summary of this article, if you don't want to read the entire thing:

• Don't use Math.random(). There are extremely few cases where Math.random() is the right answer. Don't use it, unless you've read this entire article, and determined that it's necessary for your case.
• Don't use crypto.getRandomBytes directly. While it's a CSPRNG, it's easy to bias the result when 'transforming' it, such that the output becomes more predictable.
• If you want to generate random tokens or API keys: Use uuid, specifically the uuid.v4() method. Avoid node-uuid - it's not the same package, and doesn't produce reliably secure random values.
• If you want to generate random numbers in a range: Use random-number-csprng.

You should seriously consider reading the entire article, though - it's

joepie91

Don't use VPN services.

No, seriously, don't. You're probably reading this because you've asked what VPN service to use, and this is the answer.

Note: The content in this post does not apply to using VPN for their intended purpose; that is, as a virtual private (internal) network. It only applies to using it as a glorified proxy, which is what every third-party "VPN provider" does.

• A Russian translation of this article can be found here, contributed by Timur Demin.
• A Turkish translation can be found here, contributed by agyild.
• There's also this article about VPN services, which is honestly better written (and has more cat pictures!) than my article.

denilsonsa

slow

This bash script offers quick shortcuts to simulate slower network connections. It is useful when you need to simulate a wireless network on a Linux network server, especially when you are using a virtual machine guest on your local machine or in the cloud.

slow 3G                   # Slow network on default eth0 down to 3G wireless speeds
slow 3G -l 600ms -p 10%   # slow network on eth0 and setup latency to 600ms packetloss to 10%
slow reset                # Reset connection for default eth0 to normal
slow vsat --latency=500ms # Simulate satellite internet  with a high latency

slow dsl -b 1mbps # Simulate DSL with a slower speed than the default