what do you think about a screenshot capture feature with automatic, guaranteed metadata removal?
4 Likes
Beautiful!
4 Likes
As long as it guarantees there will never be a security bug in e.g. the library displaying the image…
What metadata does the image contain anyway? And why does it contain it? Maybe the right approach should be screen capture without writing any metadata in the first place.
2 Likes
Great idea! There’s an awesome screenshot tool I absolutely love, but it lacks metadata removal.
If you implement that, your version would be the coolest!
I think after adding the ephemeral pools and screenshot, you should take a pause. Let users try out your tool and check for bugs. Also need to show it to developers.
2 Likes
If by “developers” you mean the developers of Qubes OS, that’s not that simple: it doesn’t meet some of the inclusion criteria, which is perfectly fine for a personal project.
2 Likes
By which criteria from this list does this tool not comply?
1 Like
I don’t like this approach. Regardless of its value, it feels like you are rejecting it in advance on a formality basis, instead of encouraging the user to meet the formality too, when you think this tool is great. Which it definitely is.
Almost feels like gateway keeper.
2 Likes
This moderator is known on the forum for being completely indifferent, and even hostile, toward any guides and improvements. It would be better to simply write directly to the Qubes OS team after this tool’s development is complete and receive a direct response from them.
1 Like
This moderator will always correct themself and I will always support them. This moderator never takes it personally when discussing their actions.
2 Likes
So far, I only see how he constantly drives away new guide authors or kills their motivation to do anything.
1 Like
Well I really can’t remember I ever supported some contrib as this one. This one is really rare. So, you might conclude what I think about other guides too. A piles of bash scripts which is all opposite of Qubes philosophy confirming people cannot detach from monolithic OS state of mind and world.
This one uses python and Salt, which is exactly what is promoted by Qubes. And it is indeed helpful and meaningful.
2 Likes
I agree with this, and many other users do too. That’s why we should support the creator instead of immediately saying “This is just another user project. Thanks, goodbye.”
2 Likes
this is a different surface (decoding something you received), not something this feature touches, it only covers capturing/sending.
that’s exactly the approach used, the png is built directly from raw captured pixels, never opened/re-saved, so there’s no step where metadata could get written in the first place.
on top → before it’s ever offered for sending, the file gets re-read and every chunk type checked against an allow-list (just IHDR/PLTE/IDAT/IEND/tRNS). anything else known or unknown, gets rejected and deleted.
3 Likes
He’s not deciding anything anyway.
1 Like
That was not what was said.
Inclusion Criteria
In order to be accepted, packages must:
- In no way weaken the security of Qubes OS.
I don’t know, haven’t reviewed it, just took a quick look, but so far, not liking the use of bash.
- Be published under an open-source license (read about the Qubes OS License).
Done.
- Follow our coding guidelines.
No. For starters, a lot of bash being passed to python subprocess. Prefer qubesadmin
- Be thoroughly tested.
Not done, this takes considerable time.
- Have a clearly-defined use case for Qubes users.
Multi-use tool. Would be better if things were added one by one to be considered. Some things works well for your own project but wouldn’t work well widely.
- Not be unduly burdensome to review.
Right now, it is, due to the use of bash in python scripts. Also, this _shquote can be changed to use shlex.quote. But even then, using bash should be avoided especially on interactions with untrusted input (anything coming from a qube, such as qvm-run -p).
(Please note that we always reserve the right to add criteria to this list.)
Yes.
This mini-review doesn’t guarantee anything, such as future review, I just took a quick look and wanted to tell the current state. I just reviewed because I liked, conceptually, some of the things that were done, such as installing packages in qube, filtering through list of packages etc.
8 Likes
Thanks @ben-grande for taking the time to take quick-sneak-peak. Now it’s up to @Gizooyx to reconsider your thoughts and clarifyings. I hope they will. I would be genuinely sad not to use such a tool installed from contrib repo. I am too paranoid and ignorant (in terms of reviewing the code, plus lazy to do it with AI) to use it any other way.
1 Like
This could describe me, except I was able to notice that this is a fairly large, monolithic, tool, with dangerous-looking use of qube output. Before the recent comment of @parulin above, I had decided that there was no way I would be importing it to any of my qubes, simply because of the amount of review required. @ben-grande has eloquently and diplomatically summarised concerns.
After a worrying eruption of ad-hominem responses to @parulin , I am now suspicious about the motives and affiliations involved. The MO feels almost un-humanly familiar.
It is unfortunate, but I feel that anyone who depends on the security of Qubes should adopt a position of radical skepticism about such events.
If you all are genuine, it would be better to avoid alienating the security-conscious. It is very sad -especially for @Gizooyx - but such behaviour will crush contributions far quicker than any mention of the contribution guidelines.
On the other hand, if you are trying to introduce malicious vectors into the Qubes systems of the unwary… enough said.
It is unlikely that I will be looking further at this tool, or this thread, for several weeks now.
4 Likes
Let me start by saying: I like the tool and its purpose. I am not a dogmatic proponent of the Linux paradigm of “one tool, one purpose.”
However: This tool is designed to operate in dom0 (and with elevated privileges, no less). That is, so to speak, the “Holy Grail” of QubesOS. Even the slightest suspicion of malicious behavior destroys trust in the entire system.
Before anything is installed there, it should be reviewed by several people with solid expertise in security and the inner workings of QubesOS, and unequivocally deemed “clearly non-malicious.”
This has nothing to do with the person who developed the tool—whom I deeply respect.
As a personal project where individuals can decide whether to use it based on their own judgment: an unqualified “YES.” As an official part of QubesOS (in its current state): a definite “NO.”
2 Likes
thanks @ben-grande for actually taking the time to look, genuinely appreciate a real review over just positive comments.
right now every remote-derived value does get run through shell-quoting before reuse, but correctly quoted bash is still a weaker position than no bash construction to get wrong in the first place.
agreed, and the bigger one of your points, real architectural difference, not a one-line fix…
will fix. and agree with even then same point as above, quoting correctly isn’t the same as not needing to.
also, to clear up a misunderstanding here. I personally never thought about getting this tool into the official Qubes repo. if that’s something the community actually wants, which it seems to be, I’ll look at what’s within my power to work toward meeting the criteria.
uploading today’s update (ephemeral pool + screenshot) since it’s fully working and people are waiting on it, then looking at these points step by step afterward.
3 Likes
update is live 
ephemeral pool + the screenshot capture with metadata verification are both in the repo now, along with the test suite.
have fun, let me know if anything’s not working well.
saludos,
4 Likes