• 0 Posts
  • 48 Comments
Joined 2 years ago
cake
Cake day: April 19th, 2023

help-circle
  • The title question is very broad, varied, and difficult. It depends.

    For anything that is not a small script or small, obvious and obviously scoped takes, you can’t assess at first glance.

    So for a project/task/extension like you wrote it’s a matter of:

    Is there docs or guide specifically for what I want to do/add? If yes, the expectation is it is viable and reasonably doable with low risk.

    If there is no guide the assessment is already an exploration and analysis. How is the project structured, is there docs for it or my concerns, where do I expect it as to go and what does it have to touch, what’s the risks of issues and unknown difficulties and efforts. The next step would already be prototyping, and then implementing. Both of which can be started with a “let’s see” and timebox approach where you remain mindful of when known or invested effort or risk increases and you can stop or rethink.














  • You copied that function without understanding why it does what it does, and as a result your code IS GARBAGE.

    AGAIN.

    […]

    Debate continued for some time, in a cooler tone, with Torvalds offering suggestions on what he felt would be a better approach to the issues Rostedt hoped to address.

    Harsh tone (in only two instances?), but he still invested in offering suggestions 🤷

    I expected more behind the verb “flaming”.





  • “Like any secret, SAS tokens need to be created and handled appropriately,” said the MSRC team. “As always, we highly encourage customers to follow our best practices when using SAS tokens to minimise the risk of unintended access or abuse.

    lol - follow our best practices - ironic. Of course documented best practices don’t mean everyone follows them, even internally, but that statement still makes for humorous irony. Ambiguous, almost implies, “follow how we did it here” in my reading.

    Among other things, their access levels can be easily and readily customised by the user, as can the expiry time, which could in theory allow a token to be created that never expired (the compromised one was in fact valid through to 2051, 28 years from now).

    […] it’s not easy to revoke the token either […]

    Reading this, the drive to managed cloud and centralization feels like an effort to replace memory management issues as the top vulnerability cause. We - as an industry - are more aware of those as ever, and have interesting efforts like Rust adoption. And at the same time, hierarchical access tokens you can’t easily revoke, with arbitrary configured lifetimes and access, that are hard to monitor, track, and trace (from reading this article) are introduced as an entirely new set of risk and attack surface.