wallrat

There are a few commercial products that allow you to do this also for other ecosystems (e.g. maven, nuget, pypi etc), including ours https://docs.bytesafe.dev/policies/delay-upstream/

Good to see some OSS alternatives showing up!

There are dependency firewalls that let you enforce this (e.g. https://docs.bytesafe.dev/policies/delay-upstream/). Don't know any OSS solutions though.

How does this relate to the OWASP/Ecma Common Lifecycle Enumeration Specification (https://tc54.org/cle/)?

Been tracking this project for a while https://github.com/chains-project/ghasum . It creates a verifiable checksum manifest for all actions - still in development but looks very promising.

Will be a good compliment to Github's Immutable Actions when they arrive.

Very well written (as expected) argument for RSC. It's interesting to see the parallels with Inertia.js.

(a bit sad to see all the commenters that clearly haven't read the article though)

Still have the Turbo Pascal 1.0 manual on my shelf. It was the first language I picked up after Basic and QuickBasic as a child.

Wrote a couple of interesting things a few years later in TP 5.5, including a BBS/Kom system and a MUD (with 4 dial-in lines).

Found the source a few years back, was an interesting read a few decades later.

Is there any effort to integrate SLSA with PyPI? GitHub recently announced[1] that npm support for SLSA is GA now.

[1] https://github.blog/changelog/2023-09-26-npm-provenance-gene...

> Next step ist to establish good tooling around publishing VEX statements (Vulnerability Exploitability Exchange). That is currently not easy.

Agreed.

Tooling is needed for creating/publishing/consuming both VEX statements for applications (i.e. exploitability of a dependency in context), but also VEX statements from library authors (many times the actual experts, like the OP) as a way dispute the weakness/exploitability.

Currently working hard on this [1]. When the tooling is in place the next step for the industry will be discoverability of SBOM/VEX/VDR attestations. Sigstore/Rekor [2] looks to be a viable alternative here.

> Vulnerabilities are reported (using CPE, pURL etc.) at the "library" or "application" level but they really exist at a much more granular level (e.g. a single function is affected and if that's not used there's no problem).

Again, agreed. Reachability info needs to be commoditized, standardized and shared. The current situation where it's a feature used by vendors to compete is not ideal.

[1] <https://sbom.observer> [2] <https://www.sigstore.dev>

The best kind of "problem" to have. Expect to build features, integrations and other customizations, and factor in the costs. You can do that with a higher "base" price, or include professional services into the contract (but be careful with IP rights). Use a per-seat model internally (more users = more support etc) and offer fixed price point per year. Expect to them to want to negotiate a large discount on the "list" price, so start higher than you might think.

DISCLOSURE: I'm working on commercial tooling for this exact problem [1]

> 1) What would your expectations be towards a software vendor in terms of what issues to "fix"?

I would want the vendor to communicate their analysis for all CVEs, i.e. letting us know which are exploitable or not, and what kind of response they are planning, or any fixes released.

There are efforts to standardize this workflow with Vulnerability Disclosure Reports (VDRs)[2] and Vulnerability Exploitability eXchange VEXs[3]. Both these use cases are covered by OWASP CycloneDx[4].

> 2) Is anyone aware of a security database & evaluation tool geared for vendors not for end-users?

IMHO, there are not any good tools available that solve the complete workflow. We are certainly aiming to fix that with[1], but it will take some time.

[1] https://sbom.observer

[2] https://www.cisa.gov/resources-tools/resources/minimum-requi...

[3] https://csrc.nist.gov/publications/detail/sp/800-161/rev-1/f...

[4] https://cyclonedx.org/capabilities/vex/

Interesting. Do you keep the SBOMs around after the build to track what's running in production?

Are SBOMs a "thing" yet? Is anybody using SBOMs in their day to day workflows?

The current tooling for generating them seems to have matured, but tools for storing and managing an SBOM inventory seem non-existent with exception for OWASP Dependency-Track.

Interesting. http://simpleredis.com is a similar service, but for Redis instances (for testing, CI etc), including a nice console. Instances terminates after one hour, but you can run an instance forever if you validate your email.

Been thinking about doing the same for VPS, but using LXC instead (actually already using it for internally for running tests, CI etc).

Same here.

Last week it was needing Redis slaves to handle 'SLAVEOF NO ONE' from the master without crashing. Needed to tell all read-slaves (hundreds) to stop trying to reconnect when taking the master down.

It's fine balance though, you don't want to be stuck with too many forks to maintain.

OP here, not my product, just thought it were interesting, even if hibernation files are an old classic among attack vectors.

I do work on something related though, https://scry.co that tries to protect you from the most common damage if your laptop gets stolen.

Miek Gieben's [1] DNS library [2] is truly excellent. I use it at Port 6379 for an authoritative DNS server, looking up Redis instances [3]. I too have found Go surprisingly productive and enjoyable to code, and our servers seem very stable so far.

[1] http://www.miek.nl/

[2] https://github.com/miekg/dns

[3] https://port6379.com/blog/2012/09/03/using-dns-to-find-insta...

Interesting note, 2 min after submitting to HN, someone seems to have started an DDOS against our API. Working to route around it right now.

At first we just thought it was the HN crowd storming in :-)

Thanks for the feedback! The landing page is definitely MVP, we'll see if we can find a designer to make something more inviting!

--andreas

I've spent the last couple of months trying to relieve the pains of running Redis in the cloud. I think we have come up with a rock solid backend which allows for some awesome tools and functionality.

Some highlights:

  - We support multiple clouds, Amazon US-EAST available now, 
    with beta customers testing Amazon EU-West and Rackspace. 
    More to come!
  - Your choice of Redis version. Use 2.6 RC-5 with Lua and BIT-operations.
  - A command-line tool we're happy with.
  - Simple master/slave replication config

We have a lot of interesting features coming up; secure internet access, highly available endpoints (handles server and isolation zone failures for clients), Redis analytics.

As a side note, the backend (and website) is 95% clojure and is a joy to hack on!

Your feedback is appreciated!

Looks pragmatic and useful. I've been experimenting with a similar implementation inspired by Clojure's Hiccup, but Coffekup looks mature enough to consider adopting.

I'm also pretty happy with Vimium as a former Vimperator user. The longer I use Chrome though, I find myself using the omnibox more and more for search etc. Especially when coding.

So lately I've been experimenting with https://chrome.google.com/webstore/detail/mkinfhanlabcenjnpb... to navigate links.

Works pretty good, although lot's of room for improvment.

Alternative if you don't have wmctrl installed (not default in Ubuntu for example):

  ;; Fullscreen
  (defun switch-full-screen ()
    (interactive)
    (x-send-client-message nil 0 nil "_NET_WM_STATE" 32
                           '(2 "_NET_WM_STATE_FULLSCREEN" 0)))