Sent from my mobile phone.
> On 5 Mar 2018, at 07:59, 799 <one7tw...@gmail.com> wrote: > > Hello Alex, > > 05.03.2018 8:28 "Alex Dubois" wrote: > > I think it is important to keep it as a fork for few reasons: > - most importantly we focus on helping the Qubes team > - if not it would be hard to clean-up what is in Qubes-doc, in the community > repo, and if the Qubes-doc get improved directly, it won’t be ported to > community, leading to not up to date info > > Valid points, I agree. > > However I think my suggestion is only to be taken with Qubes team validation. > And if they feel it is not the best way and prefer the mailing lists and > existing infrastructure it is important to respect that and get back in line. > > I love the work of the Qubes Team, don't get to me wrong, but I don't > understand why and how they could block the community effort to create a fork? > Some of use have already forked the docs and are currently developing their > own improved scripts. > Doing so in a collaborative and centralized way would be much better. > But - I would like to see of course - that Qubes Team is also supporting this > idea and knows about it. Same > One reason was also to indicate clearly which part of the documentation is > official and thereof reasonable secure and which is unofficial and maybe less > secure. > I definitely like the idea of an index page / rating system. > > too much resources discussing this, but rather contribute directly > > Let's go, I am ready to start. > @David (in his role of the community manager): > What do you think? > > I feel that a pair/trio need to be “responsible” per area or subject. With a > person helped by one or two for the overall. > > Yes, but we have already some interested people here, I think we only need to > discuss the approvement process and how and if of those ideas/scripts might > be placed more visible (maybe as a link) somewhere on the Qubes website which > is the main area for new users (?). I agree Approvement process should have: - initial Issue exposing the idea and the work proposed = requirements (so that we collaboratively shape what will be done, how and by who) - once this phase is done, a proper concise and precise issue can be raised to Qubes - work executed with a number of PR on Qubes-doc community (possible individual working on their own fork) - PR approved by interested moderator - once issue is felt resolved, submit PR to Qubes project (if issue was accepted by Qubes) Some issues may fall outside of official doc (issue or PR get rejected). Moderator modify issue to store the result of the work in a community doc with the disclaimer you mention (for the one where the issue is accepted by Qubes team) we put a work in progress instead. > At least a link to it, with maybe a disclaimer: > > "Take a look what is happening in the Qubes Community. > > DISCLAIMER: the content there should be treated as work in progress and has > not been reviewed by the Qubes OS Team and maybe thereof less "reasonable > secure" or maybe even opening attack vectors to your Qubes installation. > Even more if you implement a script which you haven't reviewed (and > understood) and which has not been marked as meeting the Qubes OS quality > standards. > WARNING: > If you implement changes in dom0 or the sys-VMs (sys-net, sys-firewall, > sys-usb) this might result in a total loss of security" > > For example in the Qubes-doc, there are pages to put dns, http-proxy or vpn > in line (I.e. sys-firewall). This is a bad practice as the attack surface of > one protocol is exposing the entier Qubes system. > A better way is to have these hosted on app-vm and have sys-firewall > intercepting and routing the traffic. > Even having sys-firewall doing the download rather than a dispvm is > increasing the attack surface (not sure if still the case) > > This is a good example, is there a disclaimer or security rating on the > qubes-doc pages? No that I am aware of, and this is were I slap myself on the wrist as I should have raised an issue or PR (but this may have wasted time from Qubes team) and this could be one of the issue we work collaboratively in the community repo shape and refine before sending upstream. > > [799] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/96D15406-2197-4284-94D3-DC5860E959C7%40gmail.com. For more options, visit https://groups.google.com/d/optout.
