Forum Qubes OS Forum

Welcome to the forum, @steve5 ! This is a Whonix issue, and hopefully the Whonix team will solve this by a whonix-team signed update to the tb-updater which … updates … (too many “updates”!) … the whonix-workstation-18 QubesOS template.

Hi, just another voice in the chorus-- your LLM-wrapped communication and the sequential posting of corrections does not engender confidence in your work. It causes the reader (well, this reader) to wonder if you possess the experience and expertise to be working on a project of this kind, where a bug could have major consequences to to the user. As why else would they want to be using an ‘amnesic’ system, if not for safety from some true threat? In general, LLM-generated code is only good code if it’s being guided, or reviewed, by a subject matter expert. I’m not sure if my post is meant to be a warning to a potential user, or advice to you the contributor, perhaps both.

Thanks for the suggestion. There may well be issues with Xfce that prompt such a view, but the current focus is on creating a visually appealing design that aligns with the way Qubes OS operates. Therefore, until this design is finalized, I will not attempt to move away from the Xfce environment. It might be useful to know why you don’t prefer Xfce (if you have the time).

Hello, I believe it is essential to announce the action plan, following up on my previous initiative to compile a list of contributors (I created that list primarily for documentation purposes, noting that forum interaction itself constitutes a contribution; I extend my thanks to all forum members). Action Plan Phase One This phase aims to create a visual style for Qubes that is attractive, simple, Minimalist, and modern, while preserving and building upon the system’s existing security model. I will share initial drafts to gather feedback. Once the optimal design is finalized, I will restructure it to meet Qubes project contribution requirements; this phase concludes with the project accepting the design. Phase Two This phase focuses on addressing Graphical User Interface (GUI) issues and building a tool to facilitate GUI control and customization. It concludes with the completion of an improved UI settings application, designed in accordance with Qubes project contribution standards. Phase Three This phase focuses on enhancing Qubes applications—improving their appearance and aligning them with the new visual style—and adding custom control applications featuring user-friendly GUIs. This phase concludes when no practical or feasible feature requests are received for two consecutive months. I welcome constructive criticism.

I would like to use the Cinnamon or Mate desktop.

Hi Tofu, Thank you for your contribution. Your explanation was excellent, and I’ve grasped the three points. I will take your suggestions into account and do my best. A few notes: I really appreciate your desire to develop more efficiently, but please prioritize security. I am trying to set up a Qubes system within a virtual environment so I can work without worry, so please avoid experimenting on your main system.

Hi Ahmed_iMafraid, I will explain the three ideas. Ahmed_iMafraid: Docks for each of (some selection of ) qubes is a good idea. Disabling/enabling GUI access to dom0 helps some users Different defaults for the background color of windows by qubes help correct use of qubes. For competing with other OS, (macOS, Windows, ubuntu, …), Qubes OS should have some kind of Launcher/Dock with Icons of Applications. For example, the user might put a text editor, pdf-viewer, web-browser and some devoted application for the user’s purpose. Dock shows such palette on the desktop and Launcher has the icon on the desktop and shows the palette after invocation. The user sometimes want to use different palette of applications. For example, games are on the Dock/Launcher of the private qube while devoted application for the user’s job is on the Dock/Launcher of work qube . Another way of helping the user is to provide Dock for private qube , Dock for work1 qube , …, Dock for work 3 qube. Maybe they are on the same strip, but the color of the icon distinguishes the qube. An idea for disabling/enabling dom0 access is to have a menu-item like this: from that menu-item, we can disable GUI access to dom0. This prevents accidental invocation of GUI application of Dom0. On the other hand, I am not strict about access from the menu-bar like connection to WIFI. The menu-item can enable GUI access to dom0 with authentication like the password. An example with work1 qube and work2 qube . It is a nice idea

Check whether this is a temporary tb-updater issue rather than a problem with the Whonix template itself. The download appears to start but the updater fails during the cleanup stage with END: Failed and exit code 10. As it affects the jump from 15.0.23 to 15.0.24, also check the Whonix/torbrowser updater logs for a more specific error before trying to remove anything manually. If other users are seeing the same thing at the same time, it could also be an updater/package issue that needs to be fixed upstream.

A correction to what I said about Matrix. I wrote that I added a fourth member to force a new session and got the same result. That was wrong. The run itself was no good: the test accounts still carried devices from earlier runs with no one time keys left, so sharing the key for a new session broke on its own, before any rollback. I marked that part untested at the time, but I should not have written “same result” either. Redone. Fresh accounts for every run, events counted only in the test room, and the control gate now stops the test instead of printing a line into the log. And I read the session id now, instead of inferring a rotation from the fact that the membership changed. The session does rotate. One id before the fourth member joined, another after, and the message sent after the rollback used the new one. The rolled back account did not read it. One undecryptable event. The untouched control read it fine. A run without the rotation confirms the other half: there the same rollback costs nothing. No key re-request went out on its own. That client has a single device and no key backup, though, and a re-request is answered by the user’s other devices or by the backup, so there was nothing to ask. A real client with key backup enabled may well heal where this one did not. I have not tested that and I am not claiming it. So, replacing what I said before: Matrix survives a rollback up to the next change of session, and loses reading after that. It does not soften the forwa

phceac: did you do a backup of the full disk yet? I recommend the full device, including boot and efi partitions. Everything! Not yet but yes I’ll do it now and just keep it stored while I reinstall hopefully someone helps me find the solution later phceac: I am still thinking of keyboard layout… default for early boot is en_us, but it can be changed. No it wasn’t that either I checked and it was the same symbol

I would like to welcome readers and contributors. A message to readers: This is a community-driven project that relies on contributions from the community. As a community project, it may entail security risks—a fact that all users should be aware of. I welcome any contributions or feedback. A message to contributors: To demonstrate my good faith, I apologize for not publishing the list of contributors earlier. I look forward to receiving further contributions. Content of this post: This post acknowledges all past contributors who participated in public forum discussions. It also includes all current contributors who have submitted concrete proposals for the project’s development. I apologize, but I will not mention anyone from the Qubes team or the project maintainers to avoid misleading readers; this is a community initiative that may involve security risks—a point that must be made clear to all users. (However, I thank you all for your efforts.) These are the current contributors who played a significant role in building the project through their proposals: @tofu @James369 @XenExplorer These are the individuals who shared the issues they encountered and played a key role in getting the work started: @menaby0 (I welcome collaboration if you are interested) (I have not yet compiled a complete list of names) (The lists will be continuously updated over time.) A message to the moderators: Please convert this specific post into a “Wiki post” so that I can update it regularly. I

Matrix, as promised. It does not break like SimpleX. Same test. Three accounts in an encrypted room, I roll one back to an older copy of its state, the third one untouched as a control. My own server, matrix-nio as the client. The rolled back one read the message sent after the rollback. So did the control. Nothing arrived undecrypted. Group session is why: if your ratchet state goes back you can wind it forward again and read later messages of that session, you just cannot read earlier ones. SimpleX breaks because the sender never gets a new key from the rolled back side. Added a fourth member to force a new session, same result. I do not know whether it actually rotated in my client or the missing key was just re-requested. Do not take that part as tested. First run of this was wrong and I nearly posted it. Every restart was a fresh login, so a new device with new keys, and the rolled back one was failing before I rolled it back. The control caught it. If you run this, restore the same device from the store instead of logging in, and keep the credentials inside the snapshot. Nothing changes for the rule. Reading survives, forward secrecy does not: after a rollback the other side never sees a new key, so whoever took the state keeps reading. Save forward only.