[qubes-devel] Re: Signatures on devel branches & what to track for 4.0?

2017-03-23 Thread Wojtek Porczyk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Mar 23, 2017 at 02:01:34AM -0400, Jean-Philippe Ouellet wrote:
> Hello,

Hello, Jean-Philippe,

> QubesOS/*/core3-devel branches sometimes have unsigned commits (from
> woju) at HEAD. [1] These also get merged into marmarek's remotes [2],
> still without signature.
> 
> I assume this is because there are other remotes / branches actually
> being used instead and tags are not propagating. Or does the automated
> signature verification workflow somehow break down in practice? Woju?
> Marmarek?

This is because I actually don't have my signing key in the same VM as the
development. Instead I use this [1] to sign my tags. I didn't write an
equivalent for making signed commits. Marek keeps his signing keys in the same
VM as IDE, so he signs his commits using the usual git tools.

Also, marmarek has somehow elaborate script which generally pushes only his
own tags to his repo. This stems from the times when we also had private git,
to which we pushed proprietary code (now we don't have one for common
components). Because he is the only one to push to QubesOS/* repos, those also
receive only marmarek's tags. There is one exception: core-admin/core3-devel,
which receives my tags using automated script.

My tags are to be found in woju/* repos. Those usually work, until one of us
rebases or cherry-picks something, which happens from time to time.

> Anyway... my real question is what remotes & branches one should track
> now if one wishes to follow work on R4.0? (Ideally in a state which
> one can build a "working" system from for testing.) Marmarek posted a
> builder.conf some months ago [3], but I doubt it is being used to
> actually build anything since qubes-builder signature verification
> would fail.

There are five components which have active core3-devel branches:
BRANCH_core_admin = core3-devel
BRANCH_core_admin_linux = core3-devel
BRANCH_core_libvirt = core3-devel
BRANCH_installer_qubes_os = core3-devel
BRANCH_linux_utils = core3-devel

There are some other components which have had core3-devel branches which were
then merged to master branches.

As to which repos: Probably QubesOS, but if there is no core3-devel branch,
marmarek's. I only push if I have something new, so most of my repos
are outdated. I write mostly core-admin/core3-devel, so this is the most
current (and most volatile) branch of this component, but there is also a bot
which pushes the commits to QubesOS, and the pull requests happen there, so
you may skip my repos entirely, or only fetch tags from them.


[1] https://ftp.qubes-os.org/~woju/pub/qubes-rpc/git-stag
https://ftp.qubes-os.org/~woju/pub/qubes-rpc/woju.GitSignTag
https://ftp.qubes-os.org/~woju/pub/qubes-rpc/stag.png

- -- 
pozdrawiam / best regards   _.-._
Wojtek Porczyk   .-^'   '^-.
Invisible Things Lab |'-.-^-.-'|
 |  |   |  |
 I do not fear computers,|  '-.-'  |
 I fear lack of them.'-._ :  ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY055PAAoJEL9r2TIQOiNROIwP/iiwBioOQG/htPKSiL7ZDRi/
W2vsqzVR7cRqULFxoLGQzTFYAFXbeMeYvurRnXX7eVaWiUSHqdpJuz28Qy4uWaz5
WfytKGrpCR6RPYUI584t3bvhOxow5U/WeCpbqNK5drkp8HF5sm4TiomhLl/2lTqw
LtCfiaRos/zppFMxpwldd0wjVV4eugT8Jn0Xm6cILQfNMnxAyImLz/hJjY51UdgL
LSdJwv9qPqe6M/pFHoFUsMiVIWbAVrCVZZVaS+7C/dg2uY/n7bzzMycucADdJtpn
il6UXCUn3GJlyDZabvAZVUbzJrCgIJPysJ7cSma/v6xBlNCTvkj4qqxYi/IbGhmg
ghgkPShP3zzAMlohoFtgnecfo3CdIAW2UIPDvudI9nEg+PIvYkMFvEVzXXQg759T
d5I3UIs1fmFjGKFJkYsiNCGL9vphPS2RIYFVVCUs8dj+EkWSdnamUGxSZeCwL/DM
cO8lA+uQnesm9wadTK1h8j9akMrSm5+36SiyYH0WveMe/gFAuJtVKcqTMK5amBPS
cueceBgvGEZjEMUb17PzLzExlXUobb3WSFuHXYqU/Zn6oC3NaWK9YZyXpNEvZUW4
DVxEtBERmItB4JqgKONRU5rANSvXo925OJXEaGcUkowp3S1tiATlfEpao/z9h33k
b4Noe6aUORaVhxKNrI5Y
=0rJM
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20170323100712.GN31684%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] usability request

2017-03-23 Thread Oleg Artemiev 
On Wed, Mar 22, 2017 at 5:24 PM, Jean-Philippe Ouellet  wrote:
> On Wed, Mar 22, 2017 at 8:31 AM, Oleg Artemiev  wrote:
>> Is this OK to provide a pullrequest for adding VM (qube) functionality
>> for kill / shutdown some VM using window color border as a start
>> point?
>>
>>  I'm spending some time to get into qubes manager just to kill or
>> shutdown some qube. This is a regular task in my workflow.
>
> If you are interested in quickly and easily killing a VM with visible
> windows, then update qubes-core-dom0-linux and add a shortcut in your
> desktop environment for /usr/bin/qvm-xkill. This utility lets you just
> click on a window to kill the corresponding VM.
Yes. I'm interested in exactly that. Some times I've even no time to
wait enough to allow Qubes shutdown normally.

I'd appreciate if qubes-killall will be implemented as an official
command with these abilities:

qubes-killall [no option]

used to report help. No damage by default.

qubes-killall [--also-system-qubes]

used to kill all VMs, including even sys-net , sys-whonix, sys-clock .

Some times I just need to correctly shutdown (not by holding power
button - just via init 0).
This will save alot of my timewaste wating when I'll be sure that only
power eating code are some dumb intel blobs running due to intel
design fencing.
It is not intentionally against me, but even intel has usability bugs.
Well - I've no need in otselot to empty the energy provider.
I've no that super secrets to keep moving only with battery separated
from the computing

qubes-killall [--only-system-qubes]

Yes I can script it. But lim(cost of thinking) on hacks(I do) goes
into infinity as till I'm alive.

That's why I memorize only officially supported tool names (and only
those that are helpfull to work.

BTW: I've just unintentionally reproduced the bug I'm trying to
takeover without interrupting my workflow.

This is not a single issue. This is a set of business usability issues
with different priorities. Below is proof of concept that:

1) I'm enough tired by async workflow model I usually commit my work.
2) I'm enough helpfull to get payd enough even when there's a
permanent crisys around.
3) That is proven that I committed to wait my current employment for a
half of a year period
4) I do what I really do in a long term period.

Due to that the text below officially supported by using google in
terms of transparten electronical signing till I've made a

Labelling highly depend to the product type and busness model needs.

From security perspective it is not an issue at all .

I've made a lot of efforts to defend an attack my opinion to get a
clue at what level should I mark this bug.

Due to stability of your criteria of marking some qube within a
worflow - this cannot be a security issue.

Though in terms of MPLS this is not ready enough soultion.
I would like to discuss the mathematical proof for criteria of
reasonable load stability. Since I'm finally got to commit  reboot in
two hours I've to drop all and just describe my intentions in native
language.

If you think that is not acceptable - please commit into placing a
place where native speaking is OKAY.

Для меня Qubes уже давно business ready. Я использую Qubes в своих
личных целях как операционку для лаптопа уже года 4 в режиме
"непрерывно", но с подстраховкой в виде дуальной загрузки. Потому что
бизнес требует возможности послушать скрам, а не использования скрама
для

Очень удобно. Рекомендовал бы людям с некоторым порогом входа в
осмысленность общения (модное слово социопат). Раздражение происходит
в том числе от бессмысленного переключения контекстов. В Qubes этого
нет.

Может быть рекомендовано в целях оздоровления работы с компьютером на
уровне невозможно сделать плохо и неправильно из гуя. Ну вот просто на
уровне ты ведёшь себя не правильно потому что ты сам бьёш в место
крепления нависшей над тобой массы это осознаётся влёгкую. А вот то,
что термин попаболь применяется (если не отмахиваться от проблемы
правильно формулировать свои слова. Вот это вот всё - это моё
понимание того что делает Qubes. Для начала он позволяет тебе работать
как всегда. Ты знаешь что такое виртуалка, готов пожертовать тем

Я сразу предупреждаю, что этот текст ниже - он вреден к прочтению.
Если вы достаточно спокойны и всё за то как надо делать безопасность,
то идите, защищайте ваш замок на песке прочнейшими высоченными
стенами. Ведь то что от Вас останется это очередная имплементация
защиты, не правда ли? Вы же не рассчитываете простоять столько сколько
стоит кремль или объединённые государства америки?

Ну а для тех кто хочет понять почему для того чтобы обозначить
способность тюнить концепты для Qubes Team в режиме "посоветовать идею
и посчитать что-то на своём Dom0" - добро пожаловать далее.
Дело в том что для того чтобы предоставить PoC я уже сделал достаточно
чтобы привлечь подзамковую переписку разработчиков. Неужели Вы думаете
что я пишу багрепорты в Qubes ровно с тем же намерением когда я пишу в
письменном виде

Re: [qubes-devel] Re: Signatures on devel branches & what to track for 4.0?

2017-03-23 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Mar 23, 2017 at 11:07:12AM +0100, Wojtek Porczyk wrote:
> On Thu, Mar 23, 2017 at 02:01:34AM -0400, Jean-Philippe Ouellet wrote:
> > Hello,
> 
> Hello, Jean-Philippe,
> 
> > QubesOS/*/core3-devel branches sometimes have unsigned commits (from
> > woju) at HEAD. [1] These also get merged into marmarek's remotes [2],
> > still without signature.
> > 
> > I assume this is because there are other remotes / branches actually
> > being used instead and tags are not propagating. Or does the automated
> > signature verification workflow somehow break down in practice? Woju?
> > Marmarek?
> 
> This is because I actually don't have my signing key in the same VM as the
> development. Instead I use this [1] to sign my tags. I didn't write an
> equivalent for making signed commits. Marek keeps his signing keys in the same
> VM as IDE, so he signs his commits using the usual git tools.

Actually, this is not true. I use standard split-gpg and have
gpg.program = qubes-gpg-client in .gitconfig.
This combination didn't work before because of some deadlock, but it was
fixed about 2 years ago :P

> Also, marmarek has somehow elaborate script which generally pushes only his
> own tags to his repo. This stems from the times when we also had private git,
> to which we pushed proprietary code (now we don't have one for common
> components). Because he is the only one to push to QubesOS/* repos, those also
> receive only marmarek's tags. 

This script pushes tag describing current branch, but I don't use it for
some temporary branches (mostly pushed as a backup if my machine fails,
not intended to be used otherwise), which I push without any tags,
assuming that my (signed) commit is at the top. So there may be some
branches *on my github account* without signed tags.

> There is one exception: core-admin/core3-devel,
> which receives my tags using automated script.

And this is the branch that should be used.

> My tags are to be found in woju/* repos. Those usually work, until one of us
> rebases or cherry-picks something, which happens from time to time.
> 
> > Anyway... my real question is what remotes & branches one should track
> > now if one wishes to follow work on R4.0? (Ideally in a state which
> > one can build a "working" system from for testing.) Marmarek posted a
> > builder.conf some months ago [3], but I doubt it is being used to
> > actually build anything since qubes-builder signature verification
> > would fail.
> 
> There are five components which have active core3-devel branches:
> BRANCH_core_admin = core3-devel
> BRANCH_core_admin_linux = core3-devel
> BRANCH_core_libvirt = core3-devel
> BRANCH_installer_qubes_os = core3-devel
> BRANCH_linux_utils = core3-devel
> 
> There are some other components which have had core3-devel branches which were
> then merged to master branches.
> 
> As to which repos: Probably QubesOS, but if there is no core3-devel branch,
> marmarek's. I only push if I have something new, so most of my repos
> are outdated. I write mostly core-admin/core3-devel, so this is the most
> current (and most volatile) branch of this component, but there is also a bot
> which pushes the commits to QubesOS, and the pull requests happen there, so
> you may skip my repos entirely, or only fetch tags from them.
> 
> 
> [1] https://ftp.qubes-os.org/~woju/pub/qubes-rpc/git-stag
> https://ftp.qubes-os.org/~woju/pub/qubes-rpc/woju.GitSignTag
> https://ftp.qubes-os.org/~woju/pub/qubes-rpc/stag.png
> 

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJY06QOAAoJENuP0xzK19csmKEIAIUPKDY48ON2GXh1L0LBoIGI
NsMRrnMDgWHfNb1aVWqeDDfD9jFG226TLshFTiuHk+/WsuI2kYln39KYsMDDl/AE
dxRIcMO/WsaTXSiPsLoynEMEjk6xTY10C78iuksCmvze5gTgsXBfZJXDhIW+Gd/h
Eb3poCj5j3o5qz31kquep/mGWsecNMiZnjsjBfLzrrsqlBbVRuadRce15mb/P/Tt
Y8+/c8vvv3M4aBe3tdpvyhx+K37up/NqvaLap4VK43yMU67EeK3384L1T5pfhvHN
nNfekFGEdIannGo3NDynsKAbsU9MkRwPIIu9dkVISHCf12qTMZfmtnJY5l4EKqE=
=7OlK
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20170323103142.GN1208%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] usability request

2017-03-23 Thread Oleg Artemiev 
Please do not try to get a clue why this is sent here. This is
thinking flow. I had never ever been doing a meaning full cannary and
commitment into a project.
I willl test qubes. Since I alreaday do and I enjoy Qubes OS and all
the stuff Qubes allow to born in the reality.
When you are in fear Qubes is some plcae that can support you. In
terns of tunable calm transparency.

It is really safe to use Qubes when you do it as designed. It is
enough innovative. It is already good enough to be on google summer of
code.

It's fun. Like linux was when I first met it. Enjoy!

Thank you qubes team. I've found that current sort of misfunctioning
is enough good to be not a security related problem. I've commited
into funs community just becouse  Rutkowska made a cool PoC with her
blue pill and red pill. She made me think more in context of my own
reasonse.  The real thing is that I've just committed into public that
currently I'm enough skilled to solve a pazzle "why this is a bug" and
"why this is a usability bug".
All okay. We have democracy. We have same models of goverment as a
security treat as you do in your geolocation. The laws of math is
faster to get an answer and slower to understand is stilll working for
me.
In this context I think that I made a lot to tell what is already told
))) To finalize the thread from my side I insist:

this is the load testing problem. I guess the reason is that Clock VM
is allowed to die and no default hook to restart clock VM (thinking it
has same clean state) provided
As I understand security vs usability - this is all about mistrusts
from operating system - to cleanup a block you have to unlock. But
where the lock() is subject to search.



2017-03-23 13:25 GMT+03:00 Oleg Artemiev :
> On Wed, Mar 22, 2017 at 5:24 PM, Jean-Philippe Ouellet  wrote:
>> On Wed, Mar 22, 2017 at 8:31 AM, Oleg Artemiev  wrote:
>>> Is this OK to provide a pullrequest for adding VM (qube) functionality
>>> for kill / shutdown some VM using window color border as a start
>>> point?
>>>
>>>  I'm spending some time to get into qubes manager just to kill or
>>> shutdown some qube. This is a regular task in my workflow.
>>
>> If you are interested in quickly and easily killing a VM with visible
>> windows, then update qubes-core-dom0-linux and add a shortcut in your
>> desktop environment for /usr/bin/qvm-xkill. This utility lets you just
>> click on a window to kill the corresponding VM.
> Yes. I'm interested in exactly that. Some times I've even no time to
> wait enough to allow Qubes shutdown normally.
>
> I'd appreciate if qubes-killall will be implemented as an official
> command with these abilities:
>
> qubes-killall [no option]
>
> used to report help. No damage by default.
>
> qubes-killall [--also-system-qubes]
>
> used to kill all VMs, including even sys-net , sys-whonix, sys-clock .
>
> Some times I just need to correctly shutdown (not by holding power
> button - just via init 0).
> This will save alot of my timewaste wating when I'll be sure that only
> power eating code are some dumb intel blobs running due to intel
> design fencing.
> It is not intentionally against me, but even intel has usability bugs.
> Well - I've no need in otselot to empty the energy provider.
> I've no that super secrets to keep moving only with battery separated
> from the computing
>
> qubes-killall [--only-system-qubes]
>
> Yes I can script it. But lim(cost of thinking) on hacks(I do) goes
> into infinity as till I'm alive.
>
> That's why I memorize only officially supported tool names (and only
> those that are helpfull to work.
>
> BTW: I've just unintentionally reproduced the bug I'm trying to
> takeover without interrupting my workflow.
>
> This is not a single issue. This is a set of business usability issues
> with different priorities. Below is proof of concept that:
>
> 1) I'm enough tired by async workflow model I usually commit my work.
> 2) I'm enough helpfull to get payd enough even when there's a
> permanent crisys around.
> 3) That is proven that I committed to wait my current employment for a
> half of a year period
> 4) I do what I really do in a long term period.
>
> Due to that the text below officially supported by using google in
> terms of transparten electronical signing till I've made a
>
> Labelling highly depend to the product type and busness model needs.
>
> From security perspective it is not an issue at all .
>
> I've made a lot of efforts to defend an attack my opinion to get a
> clue at what level should I mark this bug.
>
> Due to stability of your criteria of marking some qube within a
> worflow - this cannot be a security issue.
>
> Though in terms of MPLS this is not ready enough soultion.
> I would like to discuss the mathematical proof for criteria of
> reasonable load stability. Since I'm finally got to commit  reboot in
> two hours I've to drop all and just describe my intentions in native
> language.
>
> If you think that is not acceptable - please commit into placing a
> pla

[qubes-devel] How do I know - is that a MAJOR usability issue? (subject replaced)

2017-03-23 Thread Oleg Artemiev 
Hello.

Currently I'm not that busy but steel overloaded by technical debt.
I've cleaned the tech debt for some organisation units outside of my
usual daily interest.
всё хорошо. :) Баг не касается ничего существенного. Пошёл в обязательный ребут.
Сходимость очередей на запуск на уровне дребезжания фиксируется
рассчётом сходимости дискретных значений к максимально допустимой
скорости исполнения.
Это не решить костылём. Надо таймауты считать. Это вывод из моего
нагрузочного теста. Этот тест нужен мне потому что я использую Qubes в
продакшене не испытывая существенных проблем. :)

-- 
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C  9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CABunX6OKC6KwmFQaHUs6AAjaWTROf%3DxU3Rfc_hY%2BLvXs15Sz7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Signatures on devel branches & what to track for 4.0?

2017-03-23 Thread Wojtek Porczyk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Mar 23, 2017 at 11:31:42AM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Mar 23, 2017 at 11:07:12AM +0100, Wojtek Porczyk wrote:
> > On Thu, Mar 23, 2017 at 02:01:34AM -0400, Jean-Philippe Ouellet wrote:
> > > Hello,
> > 
> > Hello, Jean-Philippe,
> > 
> > > QubesOS/*/core3-devel branches sometimes have unsigned commits (from
> > > woju) at HEAD. [1] These also get merged into marmarek's remotes [2],
> > > still without signature.
> > > 
> > > I assume this is because there are other remotes / branches actually
> > > being used instead and tags are not propagating. Or does the automated
> > > signature verification workflow somehow break down in practice? Woju?
> > > Marmarek?
> > 
> > This is because I actually don't have my signing key in the same VM as the
> > development. Instead I use this [1] to sign my tags. I didn't write an
> > equivalent for making signed commits. Marek keeps his signing keys in the 
> > same
> > VM as IDE, so he signs his commits using the usual git tools.
> 
> Actually, this is not true. I use standard split-gpg and have
> gpg.program = qubes-gpg-client in .gitconfig.
> This combination didn't work before because of some deadlock, but it was
> fixed about 2 years ago :P

Nope, the deadlock you write about was related to mutt. I wrote it about
1 year ago, and I had a purpose for that. I think the real reason was that git
had some expectations about --switches, which splitgpg didn't fulfill.

And I have an audit log for all commits I signed.


- -- 
pozdrawiam / best regards   _.-._
Wojtek Porczyk   .-^'   '^-.
Invisible Things Lab |'-.-^-.-'|
 |  |   |  |
 I do not fear computers,|  '-.-'  |
 I fear lack of them.'-._ :  ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY06u5AAoJEL9r2TIQOiNRtk0QAKJh9czPMUYfAforekoLw3IK
KSjvxJH7/jJTWRMcop5Y8FR/+IGpbVZWybWE5Xi0gbLG4sNq55EzRA91pVeLyuf0
rFfzMgUgWkTwzXM6foTeX3XD2D3JuZHfplodQY5OopSWjjUunWW+WCubLrP2c1MU
De39mowTfRdakPWdXiMftTbYSdSMrRuQwn8lfSlG3fjPx0xHHf3iFBnvsSd+mJ8/
DbtZ3Y0G8ohyeIJVu4s5jch4lQ5JpViSleAsp0H9QTJ2R9TGiV6sF+cb0tiLlW+G
n2oCF2uMMpwNGozUNBjh6Ls/y9fQzTW7Wu12tSNI8bK5Gha89nDKR9APLakQcYzD
aWYV+z5ZqoQs7ohoXNAy7uUUJACK2XtdA8a23DdmtJUeltFRs0XTQSTcJOcGW15I
wHYIojX+SzhqIha/5EKhCvDzbBV0oQL+YHZQwBsd0xpHZtzHzKwaXJGOkIzndoif
ogiYBtTPlR4urMeYVXnQfqDgKPJYeXIcayNGGCLVdWIw4eWh5u6f2b3LHtPMg5Xx
3A+eUyVkEe1hqVuEaY268R9fIcyOyiKaNHZMYdxSfSDkEp9j1vNtCOhFlH6yi2/4
Bir1MPX6QiCuomgp2CrBl+iJsOwENwH5nKNLHxTu1sr+QVsGcDfQL2+Im/lAGA1T
MUOXxHpgxcdWGAip5Ubk
=RB1E
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20170323110424.GO31684%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Signatures on devel branches & what to track for 4.0?

2017-03-23 Thread Wojtek Porczyk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Mar 23, 2017 at 12:04:24PM +0100, Wojtek Porczyk wrote:
> On Thu, Mar 23, 2017 at 11:31:42AM +0100, Marek Marczykowski-Górecki wrote:
> > On Thu, Mar 23, 2017 at 11:07:12AM +0100, Wojtek Porczyk wrote:
> > > On Thu, Mar 23, 2017 at 02:01:34AM -0400, Jean-Philippe Ouellet wrote:
> > > > Hello,
> > > 
> > > Hello, Jean-Philippe,
> > > 
> > > > QubesOS/*/core3-devel branches sometimes have unsigned commits (from
> > > > woju) at HEAD. [1] These also get merged into marmarek's remotes [2],
> > > > still without signature.
> > > > 
> > > > I assume this is because there are other remotes / branches actually
> > > > being used instead and tags are not propagating. Or does the automated
> > > > signature verification workflow somehow break down in practice? Woju?
> > > > Marmarek?
> > > 
> > > This is because I actually don't have my signing key in the same VM as the
> > > development. Instead I use this [1] to sign my tags. I didn't write an
> > > equivalent for making signed commits. Marek keeps his signing keys in the 
> > > same
> > > VM as IDE, so he signs his commits using the usual git tools.
> > 
> > Actually, this is not true. I use standard split-gpg and have
> > gpg.program = qubes-gpg-client in .gitconfig.
> > This combination didn't work before because of some deadlock, but it was
> > fixed about 2 years ago :P
> 
> Nope, the deadlock you write about was related to mutt. I wrote it about
> 1 year ago, and I had a purpose for that. I think the real reason was that git
> had some expectations about --switches, which splitgpg didn't fulfill.
> 
> And I have an audit log for all commits I signed.

The tool went live on Thursday, 14.01.2016 15:28:40 CET (+0100).
Just checked from the log. :)

- -- 
pozdrawiam / best regards   _.-._
Wojtek Porczyk   .-^'   '^-.
Invisible Things Lab |'-.-^-.-'|
 |  |   |  |
 I do not fear computers,|  '-.-'  |
 I fear lack of them.'-._ :  ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY06ypAAoJEL9r2TIQOiNRogoQAK2vNQk3vcqcwIP4Wov5H3BX
GpqF+JlIJIxRrFlNIrmi9BBeIfwShduivczBMmSQRL0lzzd8ZPn1SymsZEbqbKam
ROL5Bb/Z/BmhXJySibM8Z2e1lFEUxBU7MAHsSh19cx2B6TX18soSOkeWF1OpnfjG
9vpVMkQrxNRZh9Brf2/vapCyVrG0NYdg8uTYHTOfAr/aIBFi7vSori8Xsm4B5vwX
QqL6H2XEvBskEaK2XVnnhsSojw43oo6iEdDwtKrTev/hMA3ZxPDdOR9AuTw6GbS0
RRxTBS8ZB8BHm5tg5SaUC8Cj+hGI3x3NOv32uL+taPJpqUPyBQDQc90rC483Jk5e
RiEF/CHK7F5xVEFt4ZUnl4bxYGGGLuZElW0j6lz6W1QJGXSplUuOTL+dXKSsnj8o
x1kNU0iPoiJqdcaAx/N5F9XWslUQlwLoEEdfa4TK7DP88NcvX5bOw3n/RDZLv9Ai
7e6P/JJQ1kL46RF+2EqOrFnnJL80C1M/rRxDtGIp0XDlVjz5OusSeLnGSmfekERZ
80EWT7QyTbJQThY5dJLz8+3zBTC2qLF2HIKKCEvWprFxhWaKzbE2I3QhXE3ocqkw
CjWJwMQJljwDm0SZ919oCCtfhZy9RMtnDBo9ezVi7qoWaqvnGNMm6tBHrYn4w5T+
x35YzBld7imhSg6DHgcL
=ngHS
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20170323110824.GP31684%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Why salt?

2017-03-23 Thread Chris Laprise 

On 03/21/2017 03:40 AM, max.su...@gmail.com wrote:

Sorry to piggyback on the thread, but I've been meaning to ask this.
Have there been any notable usecases of end users using salt to
coordinate Qubes VM lifecycles with salt, and orchestra/publish them
into services? I imagine something like Joanna/Marek's
qubes-app-linux-pdf-converter

which coordinates multiple VMs to produce a stronger security guarantee
than a single VM could produce.


I haven't seen any expressed on the lists.



I am unfamiliar with the structure of salt formulas and pillars, or
whether the end goal of a salt configuration can be to publish some
service endpoint (though I'd imagine the answer is yes), nor am I
certain the exact use salt has seen in qubes so far (it has been my
impression that salt helps compose qubes VMs in a  way not fully
encouraged for end user, but looking at the documentation that might
have simply been my impression given my level of understanding at the
time - it certainly seemed intimidating.) What I'm more familiar with is
Docker, where most configuration management is done via Docker file, and
coordination is done through Docker-Compose declarations.


Let me be the first to admit that salt appears difficult to understand 
at first. Their documentation drives me up the wall. It strikes me as 
the kind of project that gained followers early when it was still easy 
to grasp, then built up an obscurantist mindset.


Ansible is much easier to understand, IMHO.



Maybe I can show you guys such a file and see if Salt can do similar tasks?

This


...


Anyways, this is all kind of all over the place, and might need to be
posed elsewhere, but I'm just wondering whether salt as deployed on
qubes can covers these kinds of usecases in a fairly light weight way.


Salt probably does cover them. But I suspect Qubists have looked at the 
salt concepts and syntax and decided its not yet worth the effort.



--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/baed1035-b11d-07be-504c-8ad960dbb152%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Problems booting 4.10 kernel in HVMs

2017-03-23 Thread Nicklaus McClendon 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

After updating an HVM to the 4.10 kernel, I have noticed the HVM will
no longer boot. I have experienced the behavior on the following version
s:

4.10.5_1 (Void Linux)
4.10.0-rc6 (Debian)

I haven't seen any 4.10 guest compatibility issues with Xen, so I'm
wondering if it is a bug with the version Qubes is using. Has anyone
else experienced these problems?
- -- 
kulinacs 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPL+ie5e8l/3OecVUuXLc0JPgMlYFAljUJOMACgkQuXLc0JPg
MlYZVg/8CPMoL2IxunWE1Z171a9Doqbc9ppPdrTb80/uUs0q4uF+FYJ5Pr0Zpi17
95CGQncaSkYbJg5Jyt6szew5dCu+T542o7euvWfDj9t3weEPRAHCOzNbb59/1KuF
+FNahC0IDWlIeg9n3sCr11EwAQnkUlyRM/r4LtCx7+W4Hjka4b0raGtHvKjylqt3
cqDRG9g4MxAmishnk+QIiYyDt3lIkUZZFqHgi1R229QJap9kzKBL0B4+CSttHD4u
5ENqF40A28rJfsdjO1GwFH7i2Xuztgyy7Fx3g/EQ+KkmMfdRrLeCpZgG2yx+yNKI
gblr32FC+pyTl+e2afRF6VoSytxBve9aOM2wHn87cvwMv6FTk0o3Sz21W4u57ZJt
HTERGh2lgZpk7g4icDMz8T7nvSBZsFz4mhDXKtaOxLtGH7phkSID8huf2ZbL8hRf
1csmJuS6eKTJQefUfcbempz5YDkhqr/mw0UYLCH83YC28afC5L6NgGfYSnDv5L38
a9c+EjSoWFNzqKFJwhAkXfFIZxJ4n7+/cXUezpu6ea+DsW8nbOhsw35HOFOdyvdA
5usYn8OeGXqYmQruvfzSLCKCTghVoBsFPHCXOi47PissNuNOgkYqNho3JL1xldvb
CrNRmRR6ZLPi3ikPUerwuGKU7YHfen4Heuv5/SdrDc276zfmQqc=
=0aCY
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/9eaa6a94-a54a-c31e-cf74-5367705f0531%40kulinacs.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Problems booting 4.10 kernel in HVMs

2017-03-23 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Mar 23, 2017 at 02:41:27PM -0500, Nicklaus McClendon wrote:
> After updating an HVM to the 4.10 kernel, I have noticed the HVM will
> no longer boot. I have experienced the behavior on the following version
> s:
> 
> 4.10.5_1 (Void Linux)
> 4.10.0-rc6 (Debian)
> 
> I haven't seen any 4.10 guest compatibility issues with Xen, so I'm
> wondering if it is a bug with the version Qubes is using. Has anyone
> else experienced these problems?

Do you have any console output, any crash message?

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJY1DRbAAoJENuP0xzK19cswykIAIBeeG2H++nFKKKVKRjmEWxJ
NR2g6N91U4hg+Vea5VURxULMxPpDtMJBsPG7dQKMV/3O6SBHjIM566sZRSr/1DLP
3Kd7VUVUA+bUMvXTSgZbt2NU3MgCEiUamgmUfUXve/AB0aqmOkNc2GzcmHvIxO3D
qTg457ZWnXXZgMwD2W/2F6bD3hIyQ5nH03YCiwpAWcxFuQVTpquhfAuTRk+vUDtm
J5gpaO0ZQ25OG8Z3A9QHdZs3MjqNWvAlqK+s8w2o56CE64ZjnLolqr7gEyneJaHY
Pu0yFS4LdymtifLjQV3gDk1CRsr7L5vMYgtNlVNeVuOW8iEh3px6DlKbNV3u0qs=
=Nzhe
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20170323204722.GO1208%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Problems booting 4.10 kernel in HVMs

2017-03-23 Thread Nicklaus McClendon 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/23/2017 03:47 PM, Marek Marczykowski-Górecki wrote:
> On Thu, Mar 23, 2017 at 02:41:27PM -0500, Nicklaus McClendon
> wrote:
>> After updating an HVM to the 4.10 kernel, I have noticed the HVM
>> will no longer boot. I have experienced the behavior on the
>> following version s:
> 
>> 4.10.5_1 (Void Linux) 4.10.0-rc6 (Debian)
> 
>> I haven't seen any 4.10 guest compatibility issues with Xen, so
>> I'm wondering if it is a bug with the version Qubes is using. Has
>> anyone else experienced these problems?
> 
> Do you have any console output, any crash message?
> 
> 
It crashes while loading the initial ramdisk. In the case of Debian
the screen goes white, for Void Linux it just freezes. Neither display
any console output.

- -- 
kulinacs 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPL+ie5e8l/3OecVUuXLc0JPgMlYFAljUNpUACgkQuXLc0JPg
MlZc9A//Thy+uDaeiHBKxU0eemCVr8Y6WD7PoH9lTA7h985jQU+FKwXcM22IkwgL
I14/MvDMTW4Di3tV1aiOKq9IjVnIt5tTepAHMQei+F0yYcKwLBD4J4NM/EknHEF2
t0GLm46BSeTpUYLzQIK6klvJYGvYAAk/VrPChwzoQ1PCwSSkVYykuk18Yq6BUQtW
iY+NYfjs9p9FBrFmhoskumuLnuUEcAOXZxy+Vdwz8Uqk3Lts4+Ziu6OPIMa6fh9U
zBCIU8hZQe0kcELoJTagU87n6c9Ief19ClxP3RdeovaXpY1dsq0CofpOeHh+r7MD
qATEZWslBYMCttlLT34qNYGpE6/1fKO8XfOcgI35JEB/Jj6BJKy0r7ZbABV7z0Uj
vOcsZ32cQwA8I2Ia8ajA5xiA8EjXlR8b7bzQ3MD4zin0bboTtt/SxgxiPPRIhMiY
1SlmVUDZ1aNPCudCfrUtcZgD0AmAi/DYGFTB1OrQZoYU1iYiHfcuRNQGJDfq2QAO
t3yrZLDy90Uj2hpt+wyEKMVEv2/knE9b4Kz4Z93vfjkJVaX4XQRUEwbETpjNFC4+
7AeJuVfFziLISBQtUj059qWdGlcMw0HmFERHY/lNaJwqLy9gzD/nqyQgR2+t8DQ3
3nHmifI5ZuXdV14LPM4GKKWtK+IVYh1UnD6O26x0na6QM6U8OQ8=
=aGoz
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/7a61b5ef-bb10-6762-64d6-b175f587c514%40kulinacs.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] GSoC Student Introduction 2017

2017-03-23 Thread Alisa Matsak 
On Sunday, 12 March 2017 22:20:33 UTC+3, Jean-Philippe Ouellet wrote:

> > Please feel free to ask any questions you may have! 
>

Hi again!

Since last time I've learned some materials related to LogVM task. Now I 
want to use your offer about asking questions that I have. :)

I discovered that the majority of required functionality had already been 
implemented as a part of journald (which is a part of systemd project). 
Journald saves all the logs it knows about (such as kernel messages 
generated with printk(), userspace messages generated with syslog(3), 
userspace entries using the native API, coredumps via 
/proc/proc/sys/kernel/core_pattern and more; I took it from here: [1]). It 
also takes care of security (undetected manipulation is impossible because 
of because of each entry cryptographically verifying all previous ones) and 
journal files rotation for more efficient disk usage. At the same time it 
provides tools for comfortably viewing logs and even searching them. 
Because of the fact that all our VMs are working on Fedora, we can use all 
this features for our profit. (All of this sounds like journald 
advertisement. xD)

Journald developers advise not to change journal files because of basic 
principles of journald implementation. They describe its on-disk format and 
note that it is "not what you want to use as base of your project". I think 
that we can parse journal export format (reasoning for why this is 
necessary below) to delete meta-information, but I'm afraid journald won't 
work with our modified file later. So this way an attempt to write some 
tool for processing such files is similar to reinventing the wheel (or 
reimplementing journald).

My idea for the project is the following. Among other functionality, 
journald contains functions for sending and receiving journal messages over 
the network. For our goals we need its systemd-journal-remote [2] and 
systemd-journal-upload [3]. For transmiting entries journald uses the 
special format [4]. The problem is those tools only support transmitting 
logs in HTTP/HTTPS over TCP/IP, while we only support VMs communicating via 
qrexec. I think a simple proxy-server (maybe, even a self-written one) 
would solve the problem. Journald on VMs would send its logs to the proxy 
(that works on the same VM in the background) and it, in its turn, would 
open qrexec connection to pass them to LogVM. LogVM here would be a usual 
VM working on Fedora. There would also be a proxy-server working on LogVM 
in the background. It would receive data via qrexec and simulates for 
journald on LogVM the situation like it was received through TCP/IP. So 
this way can be suitable for collecting logs from other VMs.

For better understanding the process I attach the scheme of the described 
process [5]. Hope it will be useful.

Please, let me know what do you think about this idea. Is it suitable for 
this project? Can I write а proposal based on it?

Best wishes, Alisa.

[1] https://goo.gl/BaCCko
[2] 
https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html
[3] 
https://www.freedesktop.org/software/systemd/man/systemd-journal-upload.html
[4] https://www.freedesktop.org/wiki/Software/systemd/export/
[5] https://goo.gl/8euAAM

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/c2472d6f-b26d-4642-8e4f-a11fea924717%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] GSoC Proposal Draft: Qubes MIME Handlers

2017-03-23 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Mar 22, 2017 at 10:44:54PM -0700, Andrew Morgan wrote:
> Hello again!

Hi,

> Here is the initial draft of my GSoC 2017 proposal for Qubes MIME-type
> handling. Before I officially submit, I'd love some comments on what may
> need to be changed, added or clarified. Any and all feedback is appreciated!

Some comments inline below.

> If you would like to read the markdown formatted version, you can find
> it here (recommended):
> 
> https://gitlab.com/amorgan/qubes-gsoc-17/blob/master/proposal.md

Have you pushed it there? I see empty repository...

> Otherwise the inline version is reproduced below, thank you!
> 
> ---
> 
> # Introduction
> 
> This proposal aims to provide a detailed overview into the design and
> implementation of the automatic opening of files based on their path and
> MIME-type in a secure and configurable manner.
> 
> Currently users must use the Qubes-provided context menu actions each
> time they want to open an untrusted file. This is not only a hindrance
> to convenience, but a potential security risk if the user happens to
> forget to right-click.
> 
> In order to address these issues, the ability to "mark" a file, folder
> or an entire file type as untrusted is thus desirable.
> 
> To achieve this, a new context menu will be added to all supported file
> managers (Nautilus, Dolphin) with the string "Always Open in
> DisposableVM...".  When clicked, a dialog box will appear, allowing the
> user to choose whether to mark that file, folder and/or file type as
> untrusted. Double-clicking or opening that file in the future should
> then always result in the spawning of a DisposableVM.
> 
> # Project goals
> 
> The following steps document the required tasks for complete handling of
> trust by supported file managers:
> 
> 1. Implement python context menu in Dolphin and Nautilus as well as
>minimal GUI for modifying file trust settings
> 
> 2. Create a patch for Nautilus and Dolphin to follow these settings when
>opening a file

Patching actual file manager should be the last resort and if going that
way, patch should be prepared the way to be accepted upstream.
Much more preferred would be researching standard method for registering
handler to "open" action - preferably file-manager agnostic, but if not
possible - using official extension API of appropriate file manager (so
it will work with unmodified file manager).

Maybe something like registering file handler for "*/*" with
sufficiently high priority would work?

> 3. Create python daemon to watch and enforce file trust settings on
>files created inside untrusted folders
>
> 4. Documentation of implementation
> 
> 5. Unit testing and integration
> 
> ## Future Developments
> 
> If time permits, the following additional features will be attempted:
> 
> 1. Implement the same changes on Windows-based AppVMs
> - Hindrances include the lack of a supported Windows-compatible
> Extended File Attributes interface for python, as well as a lack of
> experience with Windows programming
> 
> 2. Implement a method for the user to tell a file is untrusted
>at-a-glance,
> such as emblems or a modified file icon
> - Nautilus still supports emblems, vanilla Dolphin currently does
> not
> 
> # Implementation
> 
> ## Implement python context menu in Dolphin and Nautilus as well as
> ## minimal GUI for modifying file trust settings
> 
> An action menu item will be added for each file manager that leads to a
> new dialog window (https://i.imgur.com/zghUUxL.png), allowing the user
> to modify current and future trust levels for that file or file type.
> 
> Action menus for Nautilus are stored in
> `/usr/share/nautilus-python/extensions/` as python scripts while for
> Dolphin are stored in `/usr/share/kde4/services/` as .desktop files. The
> GUIs for each are stored in `/var/lib/qubes/` as simple bash scripts.

I assume "/var" here is a mistake and you meant "/usr".

> The new dialog box allows the user to set that file or that file type to
> always open in a DisposableVM. If the user chooses to mark the file, an
> extended file attribute [0] will be place on the file to mark it as
> untrusted.  Furthermore, if the file type is set to always open in a
> DisposableVM, that file's MIME-type is placed in a list contained within
> a file under the user's home directory. The file will list all untrusted
> MIME-types, one per line, and is checked upon opening a file through a
> supported file manager is requested.
> 
> Additionally, just as the existing "Convert to Trusted PDF" context menu
> only appears for files, a context menu item only for folders will be
> added. This will be a simple toggle, allowing the user to mark a folder
> as untrusted. Once marked, all files and folders existing within that
> folder will also be considered untrusted.
> 
> To keep track of marked folders, folder paths are added line-by-line to
> a file in a similar fashion in how MIME

Re: [qubes-devel] GSoC Student Introduction 2017

2017-03-23 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Mar 23, 2017 at 02:28:59PM -0700, Alisa Matsak wrote:
> On Sunday, 12 March 2017 22:20:33 UTC+3, Jean-Philippe Ouellet wrote:
> 
> > > Please feel free to ask any questions you may have! 
> >
> 
> Hi again!
> 
> Since last time I've learned some materials related to LogVM task. Now I 
> want to use your offer about asking questions that I have. :)
> 
> I discovered that the majority of required functionality had already been 
> implemented as a part of journald (which is a part of systemd project). 
> Journald saves all the logs it knows about (such as kernel messages 
> generated with printk(), userspace messages generated with syslog(3), 
> userspace entries using the native API, coredumps via 
> /proc/proc/sys/kernel/core_pattern and more; I took it from here: [1]). It 
> also takes care of security (undetected manipulation is impossible because 
> of because of each entry cryptographically verifying all previous ones) and 
> journal files rotation for more efficient disk usage. At the same time it 
> provides tools for comfortably viewing logs and even searching them. 
> Because of the fact that all our VMs are working on Fedora, we can use all 
> this features for our profit. (All of this sounds like journald 
> advertisement. xD)

Not all the VMs are running Fedora, there are also Debian-based and some
people use also Arch. Not to mention also Windows, but I think we can
not care about it for now ;)
But currently all the Linux VMs do have journald (hmm, not sure about
Arch?). Using journald as a log collecting tool looks like a good idea.
But mostly because it is already there, not because we depend on some
specific feature of it. The question is how exactly (including data
format) transfer entries from one journald instance to another.

Also, if using journald for managing log storage, we need to make sure
it's reasonably configured. For example to prevent a VM to produce a lot
of log entries causing log rotation and removing very recent logs
(possibly some evidence of compromise). 

Even worse - removing not-so-old entries related to other VMs. Example
attack scenario:
1. 'work' VM got successfully attacked, but Log VM got evidences of the
attack
2. Compromised VM start a new DispVM
3. That DispVM produce a lot of rubbish log entries, causing all the
recent logs to be rotated and removed
4. Compromised 'work' VM also clean local logs (if any)

Now, the only thing you have in LogVM is some garbage sent by a random
DispVM and you don't even know which VM started that DispVM (because
that log entries were rotated too). While you may suspect that it isn't
only DispVM that got compromised, you have no idea which VM it is and
what exactly have happened.

Probably some rate-limiting (maybe connected with alerting) should solve
this problem, but we need to think about such scenarios.

> Journald developers advise not to change journal files because of basic 
> principles of journald implementation. They describe its on-disk format and 
> note that it is "not what you want to use as base of your project". I think 
> that we can parse journal export format (reasoning for why this is 
> necessary below) to delete meta-information, but I'm afraid journald won't 
> work with our modified file later. So this way an attempt to write some 
> tool for processing such files is similar to reinventing the wheel (or 
> reimplementing journald).

Using full journald export format isn't a good idea, at least for those
reasons:
 - many fields should be out of control for sending VMs - for example
   hostname, timestamp, but probably more
 - many fields are unnecessary (for example all __*), so lets keep the
   attack surface as small as possible; even Lennart Poettering can't
   write bug-free code ;)
 - for the same reason, I'd filter out binary entries (replace
   non-printable characters with dot, underscore or sth like this) -
   even if journald itself handle them well, some log-viewing software
   may not; even simple 'less' command throw a bunch of parsers on its
   input...

If using this format, I'd use some simplified version - filter out
unneeded fields (most of them?) when sending, and synthesize those
required after receiving entry in LogVM. And of course reject entries
not conforming to this simplified specification.

To be honest, I think the "short" format (`journalctl --output short`),
with timestamp and hostname stripped off is enough. So, basically just
MESSAGE field from "export" format.
If that means the need to synthesise all the other fields (which I
doubt), lets be it.

> My idea for the project is the following. Among other functionality, 
> journald contains functions for sending and receiving journal messages over 
> the network. For our goals we need its systemd-journal-remote [2]

Looks like this tool can accept input not only from the network, but
also from a local socket :)

>  and 
> systemd-journal-upload [3]. For transmiting entries

Re: [qubes-devel] DNS, NTP, and resolv.conf

2017-03-23 Thread daktak 
Any updates on this?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/9414681c-1ca6-4c96-bff3-0a9e30ab4983%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] How do I know - is that a MAJOR usability issue? (subject replaced)

2017-03-23 Thread Andrew David Wong 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-03-23 03:45, Oleg Artemiev wrote:
> Hello.
> 
> Currently I'm not that busy but steel overloaded by technical debt.
> I've cleaned the tech debt for some organisation units outside of
> my usual daily interest. всё хорошо. :) Баг не касается ничего
> существенного. Пошёл в обязательный ребут. Сходимость очередей на
> запуск на уровне дребезжания фиксируется рассчётом сходимости
> дискретных значений к максимально допустимой скорости исполнения.
> Это не решить костылём. Надо таймауты считать. Это вывод из моего
> нагрузочного теста. Этот тест нужен мне потому что я использую
> Qubes в продакшене не испытывая существенных проблем. :)
> 

Please don't post to both lists:

https://www.qubes-os.org/mailing-lists/#specific-rules-and-notes

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJY1HcoAAoJENtN07w5UDAw740P/jkfgpCRyEp4cs/lcoqpcREm
taXGXqMUqK0Elv/r+g2jcfDjwLWzoNUXld5/sauPJZaNbnVAOEi0xNah2ltdtDGw
YSF0hSUV9MKjksnjpgCE5jJUlIBBFTVgV1EYzcSVkFFoVGDhEs0xlOwr/Q10DlCB
eScabhEIPGjh1D3hR5Fn6NkzTCNFiZXn4HL00Zf7QFlpDlbm61/+CAJ+/RQbToTw
xBhiblnPt64SMXhn57s3zuuw0EGKuhBniddOKu7FjvXtt8vDSV4c/smB/olBxjyD
aBXxWxHXUd6f+UyQLhRNdhjlFT6ofTGDHVADLnHo/0LmMgEsh4OT34h2HSJaqXBW
65bOKfmiwsCsESs+USE0zJb3XEnTAuyMeA8wBmOU4EHH9T9nElOzjKphAMGv4fxw
NkKyK5GDISeUfILMr+tT9AmzwF1+A0ncplD8KpwTceD+MtDbOai/BLXPs6kGmrhy
+oZAefsF9neLPA24lE9Q5GD6qGKoakPOc9X/VxGtVWfBwn6yLpVfQkUCcP4mRela
4MACKuEzrBPfht/0uEQSCrlFvYcwqMsGSQtHwtrUq9P1GIanwdMyfGhqJYVbD1F2
8R5MqczIvfComwYvGybjcR/pP+jtIdyyou6n4Chn+a3ngxqtU96H8te8LQcbVrQz
djQ8r+ViCwdeXGM8Gbxx
=VUes
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/a6457588-11a1-c7c1-42c3-81a8e143e4b7%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Re: Why salt?

2017-03-23 Thread Andrew David Wong 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-03-23 10:06, Chris Laprise wrote:
> On 03/21/2017 03:40 AM, max.su...@gmail.com wrote:
>> Sorry to piggyback on the thread, but I've been meaning to ask this.
>> Have there been any notable usecases of end users using salt to
>> coordinate Qubes VM lifecycles with salt, and orchestra/publish them
>> into services? I imagine something like Joanna/Marek's
>> qubes-app-linux-pdf-converter
>>
>> 
>> which coordinates multiple VMs to produce a stronger security guarantee
>> than a single VM could produce.
> 
> I haven't seen any expressed on the lists.
> 
> 
>> I am unfamiliar with the structure of salt formulas and pillars, or
>> whether the end goal of a salt configuration can be to publish some
>> service endpoint (though I'd imagine the answer is yes), nor am I
>> certain the exact use salt has seen in qubes so far (it has been my
>> impression that salt helps compose qubes VMs in a  way not fully
>> encouraged for end user, but looking at the documentation that might
>> have simply been my impression given my level of understanding at the
>> time - it certainly seemed intimidating.) What I'm more familiar with is
>> Docker, where most configuration management is done via Docker file, and
>> coordination is done through Docker-Compose declarations.
> 
> Let me be the first to admit that salt appears difficult to understand
> at first. Their documentation drives me up the wall. It strikes me as
> the kind of project that gained followers early when it was still easy
> to grasp, then built up an obscurantist mindset.
> 
> Ansible is much easier to understand, IMHO.
> 
> 
>> Maybe I can show you guys such a file and see if Salt can do similar
>> tasks?
>>
>> This
>> 
>>
> ...
> 
>> Anyways, this is all kind of all over the place, and might need to be
>> posed elsewhere, but I'm just wondering whether salt as deployed on
>> qubes can covers these kinds of usecases in a fairly light weight way.
> 
> Salt probably does cover them. But I suspect Qubists have looked at the
> salt concepts and syntax and decided its not yet worth the effort.
> 

Yes, we need better documentation to make Salt accessible:

https://github.com/QubesOS/qubes-issues/issues/1983

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJY1HmqAAoJENtN07w5UDAw3yUQAKJ/gSSrwhdOWifuSmeiu8vh
PxIXwtoc3tGXJIqUnNkcE9avTmCpzYhHp86WnXaK3vk1dfkr8F/RdSW0CGYkqHl2
2l83sY8Ol3qC1OqDhlegH9UDQCYh5UL7FzEWnr8OIXYrmlj67d1jpWJK2W8V7Cgd
U1COWlkWr+LnWJEyK1FBjlj9cMqPeaODcpI6DpjB6ZLizffRVywsYlhcQCDHSTS3
JK5wke9jX/6Em1RMdkR0WA6vL50qTLDPxprjW8KD4IGSWWijryvAVIQGmFn2J9WY
34ej9RJst1jmX0a1Z2fqFtRS8yrcrJJgxaJB7l1i1ucoCcpvdrL1qUwyA/6jjs6M
uDaCDthm/jfFl1VK4R+rYqwGB+/kr9l68dzO/Iauk4ZJKEkIKojmKAIRP975EpGT
3xJ0pW8f91pBsBc0aDOEmQAQSEYbGKpWShgtMGmhbvDRfGISPmAOUpI5p3WZd8/E
qW4F0GDkOKldkG6DZYl295skGZNaH7UFUy4+rELmgtleRKksFNL62ShDOb96wy+8
3Hci2paTXJR/pc5ha/pl3+nI7CeSwMNCHZqQ5zxrPCbnFS+PYrQsImoUALYaajEA
VSJViLQ3KZwyDzj1oOg9xe1aNXzIb9kjRTzesiPSaqblA5nAi4X1o69vAFVk2Bd8
C1Wyh5Ky1Gn3ytcOYT4q
=mdc5
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/f9daada3-fed5-1ecd-4f37-fcef18f8299c%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.