Konform Browser and other bits and bobs.

  • 22 Posts
  • 159 Comments
Joined 3 months ago
Cake day: January 18th, 2026
  • ken@discuss.tchncs.detoPrivacy@lemmy.world•PeerBox, the first fully P2P secure email systemEnglish
    14·
    10 days ago

    Thanks for the detailed review

    I wouldn’t call that detailed. It was what glared at me from skimming for a couple of minutes.

    was calling pip install --break-system-packages at runtime, which is indefensible

    “You” still have three instances left of runtime pip install --break-system-packages without user interaction, one of which dead code.

    I think the follow-up beautifully clarified the “is this vibecoded?” question too.

    Labeling it 1.0.0 seems premature to say the least.

  • ken@discuss.tchncs.detoSelfhosted@lemmy.world•How Do you keep your services updated?English
    1·
    14 days ago

    A dedicated Forgejo instance f.example.com.

    For a small set of trusted “base” images (e.g. docker.io/alpine and docker.io/debian): A Forgejo Action on separate small runner, scheduled on cron to sync images to f.example.com/dockerio/ using skopeo copy.

    Then all other runners have their docker/podman configuration changed to use that internal forgejo container registry instead of docker.io.

    Other images are built from source in the Forgejo Actions CI. Not everything needs to be (or even should) be fully automated right off. You can keep some workflows manual while starting out and then increase automation as you tighten up your setup and get more confident in it. Follow the usual best practices around security and keep permissions scoped, giving them out only as needed.

    Git repos are mirrored as Forgejo repo mirrors, forked if relevant, then built with Forgejo Actions and published to f.example.com/whatever/. Rarely but sometimes is it worth spending time on reusing existing Github Workflows from upstreams. More often I find it easier to just reuse my own workflows.

    This way, runners can be kept fully offline and built by only accessing internal resources:

    • apt/apk repo mirror or proxy
    • synced base container images
    • synced git sources

    Same idea for npm or pypi packages etc.

    Set up renovate1 and iterate on its configuration to reduce insanity. Look in forgejo and codeberg infra repos for examples of how to automate rebasing of forked repo onto mirrors.

    I would previously achieve the same thing by wiring together more targeted services and that’s still viable but Forgejo makes it easy if you want it all in one box. Just add TLS.

    1: Or anyone have anything better that’s straightforward to integrate? I’m not a huge fan of all the npm modules it pulls in or its github-centric perspective. Giving the same treatment to renovate itself here was a little bit more effort and digging than I think should really be necessary.

  • ken@discuss.tchncs.deOPtoArch Linux@lemmy.ml•PSA for AUR users: Don't fall behind on browser updates
    1·
    14 days ago

    Is there something particular going on or that has occurred to make you say this? Wondering what I’m missing.

    Not one thing in particular but a general trend driven by several factors. Things recently have, are, and will continue to heat up.

    For one, past few months a few significant supply-chain attacks have been hitting popular developer tooling and libraries used for web development. As devs get compromised, this will “trickle down” to users.

    For two, as stakes are rising, devs are burning out and the economy is shifting, crap like this is just considered “Monday” now. Already been common with browser addons for a while now.

    As for browser themselves, take a closer look at release notes and changelogs (for forks, go to upstream). Note the number and severity of addressed issues and update frequency.

    Adoption and evolution of LLMs also tie into this in multiple ways. Others have written in length about this. If there is one thing doomers and hypers agree on, it’s this.

    Oh, and be careful with archive links.

  • ken@discuss.tchncs.detoCybersecurity@sh.itjust.works•DevSecOps Tools?English
    4·
    28 days ago

    Hard to give good advice without knowing more where you’re @. Leaving out the human and organizational aspects, which might be at least as important:

    It could do you well to “harden” your environment and take a hard look at the software you are already running, what it does, and how it got there. Try to remove rather than add. Reduce your surface-area and exposure. Consider what options you have to isolate and “lock down” what remains.

    Cut out or replace any software that calls home. Isolate and sandbox things. Take a critical look at your supply-chain(s): Are you satisfied with your repos/registries/installation methods? How auditable are your services in reality? Can you improve on that? Are there things that should be mirrored and/or built from source? (BTW, reading the source of the stuff you use and rely on and building it is a good exercise in itself whether you end up relying on the output or not)

    Get familiar with relevant monitoring and debugging tools for whatever you have. Learn how to verify and validate your assumptions of “what is going on”. This probably involves getting comfortable and intimate with traditional data-engineering processes and tooling.

    This applies to everything: shared infrastructure “in the cloud”, IDE and browser on your local workstation, transitive dependencies of apps you are working on and their toolchains, etc.

    Maybe you need/want to set up some mirrors and dedicated CI. Forgejo is one easy way to get started as it comes with a lot of the components you need in one package.

    If not used to doing so already, force yourself to think from first principles. Take less things for granted. Practice active threat modeling. Think about trust. Audit yourselves.

    The “Sec” part is more about processes, focus and mindset. What tools are important can vary widely depending on what you have to work with.