HN user
Currently working on a way to help folks setup a signal account without requiring a smartphone.
It's in rust with egui, and should help folks to do that without the cli.
Not ready for prime time yet, but available at https://github.com/almet/signal-without-smartphone
(Hi, disclaimer: I'm one of the current dangerzone maintainers)
You are correct: that's basically what Dangerzone is doing!
The challenges for us are to have a sandbox that keeps being secure and make it possible for non-tech folks (e.g. journalists) to run this in their machines easily.
About the sandbox:
- Making sure that it's still updated requires some work: that's testing new container images, and having a way to distribute them securely to the host machines ;
- In addition to running in a container, we reduce the attack surface by using gVisor¹ ;
- We pass a few flags to the Docker/Podman invocation, effectively blocking network access and reducing the authorized system calls ;
Also, in our case the sandbox doesn't mount the host filesystem in any way, and we're streaming back pixels, that will be then written to a PDF by the host (we're also currently considering adding the option to write back images instead).
The other part of the work is to make that easily accessible to non-tech folks. That means packaging Podman on macOS/Windows, and providing an interface that works on all major OSes.
(Hi, disclaimer: I'm one of the current dangerzone maintainers)
That's a good question :-)
Opening PDFs, or images, or any other document directly inside your machine, even with a limited PDF viewer, potentially exposes your environment to this document.
The reason is that exploits in the image/font/docs parsing/rendering libraries can happen and are exploited in the wild. These exploits make it possible for an attacker to access the memory of the host, and in the worse case allow code execution.
Actually, that's the very threat Dangerzone is designed to protect you from.
We do that by doing the docs to pixel conversion inside a hardened container that uses gVisor to reduce the attack surface ¹
One other way to think about it is to actually consider document rendering unsafe. The approach Dangerzone is taking is to make sure the environment doing the conversion is as unprivileged as possible.
In practice, an attack is still possible, but much more costly: an attacker will be required to do a container escape or find a bug in the Linux kernel/gVisor in addition to finding an exploit in document rendering tools.
Not impossible, but multiple times more difficult.
¹ We covered that in more details in this article https://dangerzone.rocks/news/2024-09-23-gvisor/
(Hi, dangerzone maintainer here)
There is indeed a dangerzone-cli tool¹, and it should be made more visible. We plan on updating/consolidating our docs in the foreseeable future, to make things clearer.
Also, plans are here to make it possible to use dangerzone as a library, which should help use cases like the one you mention.
¹ https://github.com/freedomofpress/dangerzone/blob/main/dange...
Freedom of the Press Foundation is kick-starting a bug bounty program for this holiday season.
Challenge the popular adage "containers don't contain", by sending Santa a naughty letter that bypasses Dangerzone protections (Libreoffice + gVisor + Podman)
If your letter breaks a containerization layer by capturing a flag, you get the associated bounty.
Have fun!
I'm not sure the ratio of comments to LoC is a sign of good quality code.
Too many comments might actually be a bad thing. It's more lines to maintain, and sometimes the comments just tell what the code is doing where there is no need to.
I'm not sure it's not do-able, actually. What about having an execution sandbox and a way to check the calls made during the execution of the install script for instance?
I worked a few years back on something like this but it went nowhere, but I still believe it would be doable and useful. The only trace I found back is https://wiki.python.org/moin/Testing%20Infrastructure, which contains almost no info...
I still have a hard time understanding what's going on with startups : the power of money makes it too attractive to sell and "call it a life" I guess. That's why even if they don't plan on doing this, startup might actually accept being bought. I guess.
It's still the same story : PyPI still doesn't have a way to automatically detect interactions with the network and the filesystems for the submitted packages. It's a complex thing to do for sure, but that would be a welcome addition, I guess.
Aren't startup made to be bought by the tech giants? Until there is a shift in their goals, I can't see thé gafam losing here.
Is DjangocCon US still worth it in 2022? I've been to some PyCon US in the past and it was really a great way to meet the community. I wonder if it's still playing the same role in 2022, or if the community is harder to approach?
The only thing that bugs me with Proton is that it's still very complicated to integrate with thunderbird (or any mail app?), which makes it practically unusable for my needs.
Having a tab always open in my browser for my mail seems so wrong.
Thanks for stating this. It's still good to have people working on tools to help us have better usable solutions though.
Depending who is your enemy (threat model), I guess proton tools can help you protect your intimacy though.
In french we say GAFAM, I naively though it was the same in the US. Gasp, I'm still too focused on my culture =D
It's frightening to see how the nuclear power debate is done nowadays.
Yes, nuclear energy is generating less CO2 than some other forms of energy, but saying it's saving lives seems sketchy at best, and to be used as a "hammer argument". Because it's "saving lives", it's good.
All energy producing less CO2 than the current mix is "saving lives" in a way. So yes, we should aim for less production of CO2. There is no question here.
But I believe that in order to have a opinion on the matter we need to understand the whole picture.
- *Waste* : we don't really know what to do with them. We pile them up and try to protect humans from them, but really we don't know what to do more than that.
- *War risk* : if a plant is a military target, it might cause big trouble to the population around, and to the nature…
- *Dismantling* : we still don't know how to dismantle a nuclear power plant and we don't know the energetic cost of doing so. Still, we have many nuclear plants that are coming to their end of lives, and we still don't know how to so properly.
- *We don't have sufficient sources of uranium* : it seems that we lack some uranium in order to produce enough energy in a sustainable way.
- Also, uranium extraction is complex geo-politically and seems to creates a geographic context keen to a war on resources, especially if we don't have enough.
So, it might "save lives" wrt CO2 emissions, but that doesn't necessarily mean that it's a clean energy, nor that's the energy of the future, in my opinion.
This is a mathematical approach to music, and lacks (from my point of view) what is the mere essence of music : choice.
I understand why they want to take back the copyright on music, but they do so in such a geeky way that it seems completely useless to me.
Ultimately, musicians will pick good / cool melodies from this dataset, in the same way they do when in front of an instrument.
I might be missing the point ?
Does it really pays better? I thought that cooks aspired to own/operate a restaurant because they think they'll be able to do the stuff they want the way they want.
It really seems they're trying to get things right, but are afraid of the competition. In my opinion this is because the company and the product is new to the market. Once they know that their income isn't tied to them being closed-source, they might change their position on this, or they will keep their customer locked-up because they're afraid of them running away.
This seems to be missing the point : Freedom for the users on one side, and sharing knowledge on the other side.
Here you have neither of the two and the only reason is fear. If your startup isn't successful and you have open-sourced your code, it's probably not because of the competition using your code, but because you're not solving a problem that people need to be solved.
Resonate is nice and I like the fact that it's a co-op, but there is something missing that was present on band-camp, unless I missed it: the possibility to pay for real albums that will be shipped to you, or for you to download the .flac or .mp3 files to add to your library.
It's actually possible to download the files but the price is fixed and it seems to be track by track.
So it looks more like a replacement for Spotify to me.
It's really sad to see these almost "public goods" platforms be acquired by other companies, which will probably turn them in something else at some point because their vision isn't the same.
This could probably be avoided by using different strategies. For instance, if Bandcamp was an NGO of some sort, or has a social contract attached to it, etc. it could have terms for not being acquired.
You, capitalism. Again.
Thanks for the info and the work done.
I don't quite understand how this fits in the picture of other package managers. If it's capable of being a multi-platform package manager, that would be great, but I suppose it's a complex task to have software and libraries running on all operating systems without any difference in usage.
Is it a stated goal of this tool? Am I looking at this the wrong way?
Might be surprising to some, but the fediverse has good uptaking in France, and the name sounds good to French people I know :-)