Skip to content
Commit f823c912 authored by Rene Engelhard's avatar Rene Engelhard
Browse files

update patches/apparmor-updates.diff based on master (child profile for gpg)

parent eee0097a
Show whitespace changes
Inline Side-by-side
  • Rene Engelhard @rene ·
    Author Owner

    which does a bit more, like importing keys etc. for enigmail. I don't believe it's LOs job to manage keys, in fact it would open gpa, etc for that, so key management should be gnupgs job (and gnupg doesn't have a profile either way)

    Or do you mean gpg-via-gpgme needs more than what is the profile right now?

  • Vincas Dargis @Talkless-guest ·
    Contributor

    Since /usr/bin/gpg and /usr/bin/gpgsm are executables, they should not event start without at least having #include <abstractions/base> for loading basic libraries and without having ability to read itself for execution without /usr/bin/{gpg,gpgsm} rm rule. I imagine it should be something like this:

    profile gpg {
    #include <abstractions/base>

    # Main executables    
    /usr/bin/{gpg,gpgsm} rm,

   owner @{HOME}/.gnupg/* r,    
}

    Anyway, if I would find time to test and improve LibreOffice AppArmor profile, I guess I should send patches to https://cgit.freedesktop.org/libreoffice/ instead of creating merge request here, is that right?

  • Rene Engelhard @rene ·
    Author Owner

    Hmm, ok. But shouldn't the be covered by the main profile?

    Anyway, if I would find time to test and improve LibreOffice AppArmor profile, I guess I should send > patches to https://cgit.freedesktop.org/libreoffice/ instead of creating merge request here, is that > right?

    Either way is fine by me. In the first case we can upstream this (if you write the copyright statement...)

  • Vincas Dargis @Talkless-guest ·
    Contributor

    But shouldn't the be covered by the main profile?

    No, child profiles does not inherit rules from the parent. They are simply sort of convenient way to declare profile within a profile.

    You can do a quick grep to see some more examples of these full-fledged-profiles-within-profiles:

    sudo grep -P -e "profile.*{" -A10 /etc/apparmor.d/*

    Either way is fine by me. In the first case we can upstream this (if you write the copyright statement...)

    Sorry, I do not follow. Why would "either case" would be fine? Wouldn't that mean that Debian and upstream profile would diverge?

    Or maybe there is some sort of sync from-Debian-to-upstream done regularly?

    And could you elaborate about that copyright statement too?

    Thanks!

    Edited by Vincas Dargis
  • Rene Engelhard @rene ·
    Author Owner

    argh. so I guess I'll simply revert this. Since this is too much work for a simple "sign and encrypt document" thing.

    Sorry, I do not follow. Why would "either case" would be fine? Wouldn't that mean that Debian and upstream profile would diverge?

    Yes, at least temporarily. That said, there's no known consumer other than us anyway. Even Ubuntu who wrote this profile apparently don't really care, otherwise they would have fixed some bugs I fixed in the profiles lately themselves...

    Or maybe there is some sort of sync from-Debian-to-upstream done regularly?

    You can also submit it upstream. But yeah, I do upstream stuff I do which could be upstreamed.

    And could you elaborate about that copyright statement too?

    https://wiki.documentfoundation.org/Development/GetInvolved. Search for "statement".

    Edited by Rene Engelhard
  • Vincas Dargis @Talkless-guest ·
    Contributor

    Since this is too much work for a simple "sign and encrypt document" thing.

    Maybe AppArmor needs abstraction or named profile for GPG stuff to avoid duplication, because I see it's a at least second (with Thunderbird) application that uses AppArmor and tries to sign stuff. So it could be like that:

    /usr/bin/gpg rmCx -> gpg,

profile gpg {
 #include <abstractions/gpg-common> # all the basic stuff
 
 # some LO-specific rules here, if any
}

    That said, there's no known consumer other than us anyway.

    In this case, I would like this (salsa.debian.org) interface more that that upstream Gerrit, if that's woundn't make too much extra work for the maintainer :) .

    https://wiki.documentfoundation.org/Development/GetInvolved. Search for "statement".

    Oh so I have to send them email with statement. OK, I'll make sure I do that before starting making contributions.

  • Rene Engelhard @rene ·
    Author Owner

    did discuss this on #apparmor on IRC just now since the profile didn't work even with the old version without child profile and we fixed the profile up:

    d87efd04

  • Vincas Dargis @Talkless-guest ·
    Contributor

    @rene I am a little confused about how workflow would look like when developing AppArmor-related fixes.

    I see this commit is for a patch file, meanwhile there was also a commit in upstream repo directly into sysui/desktop/apparmor/program.soffice.bin.

    What steps should I preform to prepare for a development? I guess I checkout this repository (master? debian-experimental-6.0/1?), download upstream sources, apply apparmor-x Debian patches, and then after updating that latest updated AppArmor profile that I put into /etc/apparmo.d, I somehow update ar create a new patch file.. or something like that?

    Or I should actually reconsider to work with upstream Gerrit and push changes directly there? But that means that Debian will not have fix until upstream releases new version..?

    Your input is really appreciated!

  • Rene Engelhard @rene ·
    Author Owner

    I don't get the question at all, sorry.

    I see this commit is for a patch file, meanwhile there was also a commit in upstream repo directly into sysui/desktop/apparmor/program.soffice.bin.

    I actually did it upstream first. And yes, of course I updated the patch file then for the new rules.

    What steps should I preform to prepare for a development? I guess I checkout this repository > (master? debian-experimental-6.0/1?),

    Right now for 6.0 t's -6-0. soon it will be master. master is "Debian sid" basically.

    download upstream sources, apply apparmor-x Debian patches, and then after updating that latest updated AppArmor profile that I put into /etc/apparmo.d, I somehow update ar create a new patch file.. or something like that?

    Yes, basically. In this case I hand-edited the patch, but yes.

    Or I should actually reconsider to work with upstream Gerrit and push changes directly there? But that means that Debian will not have fix until upstream releases new version..?

    Or until that fix gets backported. Your second step btw is not in any way different to the first. If you checked out upstream and create a new patch file (note you need to also include earlier commits) you will need to update the patch file in Debian as well.

    Regards,

    Rene

  • Vincas Dargis @Talkless-guest ·
    Contributor

    OK so I'll try to fix that simple /sys/devices/virtual/block/dm-0/queue/rotational DENY message by sending fix into upstream Gerrit, and I'll try to update that apparmor-updates.diff here, see how that goes...

  • Rene Engelhard @rene ·
    Author Owner

    OK.

    To be honest, that "check whether the disk is a HDD or a SSD" check is (afaics) just for performance improvements on startup, so I didn't consider that too important to deal with. The signing stuff is/was more important. But yeah, you can try :)

  • Rene Engelhard @rene ·
    Author Owner

    https://cgit.freedesktop.org/libreoffice/core/tree/desktop/unx/source/pagein.c#n48

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment