finnigja

ruh roh... "no secure protocols supported", per https://www.ssllabs.com/ssltest/analyze.html?d=00f.net

> ... one common reason is that security engineers are shared across a large company and it may be very expensive for them to learn the different testing frameworks used on many different projects

That's where the partnering part of the approach I'm proposing comes into it. The security engineer isn't off there by themselves trying to figure out it, but is working with somebody who's already familiar with the existing code base & testing frameworks.

> also, independent review (without any exposure to developers' conceptions about what should be tested, or why, or how) may be economically justified because outcomes of security bugs are sometimes much worse than outcomes of many categories of ordinary bugs.

Economically justifiable perhaps, but that doesn't necessarily mean we shouldn't explore better ways of achieving similar outcomes.

> Other reasons may include that the security engineers want to run a test that can't be expressed in your testing framework without a huge change to the framework, they may want to develop their test cases adaptively such that most of the tests turn out to be useless and the cost of capturing every test under version contol may be very high, they may want to run tests from a commercial testing product for which the license does not allow bulk copying of the tests into a customer's testing framework, or (if they aren't in-house engineers) their business model is that they won't tell you every test that was run unless there's an associated defect finding.

Yeah, this'd be interesting to experiment with. The accepted model of security testing being separate allows this uncoupling of tooling / process, but .. perhaps the outcomes of a more-tightly-coupled testing methodology would be better?

I don't think any of these points are blockers, more just factors to consider or trade-offs to balance when exploring alternative, less separate, approaches.

That particular structure hasn't really taken off, but the general idea of having unique-ish token formats that can be mapped back to a provider is becoming more popular.

Trivy has a pretty good collection of examples that is used for its secret scanning functionality, https://github.com/aquasecurity/trivy/blob/main/pkg/fanal/se....

I'm building an interactive, web-based Python tutorial site intended to help with learning basic syntax. Originally it was for my kids who wanted to learn to code, but... might be useful to others.

https://learnpy.dev

The content needs some work, but I'm pretty happy with the framework / UX. I would love to get any feedback from folks who check it out!

(The first section is just multi-guess questions as part of the introductory content. Try any other section to get the full in-browser-code-execution experience, which uses client-side Pyodide under the hood.)

Another take on this I like is "radiating intent". Broadcast what you want to do, when you plan to do it, and give stakeholders space to explicitly object, rather than explicitly chasing consensus / alignment / approval. Works in some scenarios, and generally requires baseline trust to have been earned.

https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...

Haven't look at that code for a while, but IIRC it does a simple HTTP request then checks the returned HTML for anything that looks like a v4 literal, eg. http://174.136.109.18.

Not hard, just different. Maybe the "harder" bit is actually remembering any one address.

My IPv6 connectivity tester at https://ready.chair6.net is still doing its thing, twelve years since https://news.ycombinator.com/item?id=2154124.

Looks like Hacker News has added support in five years since https://news.ycombinator.com/item?id=21382275.