[apparmor] GSoC week 1

[Christian Boltz]

Hello,

some short feedback on 
http://kshitijblogs.blogspot.in/2013/06/week-0-coding-period-begins.html

> Work on config module, which is basically a tool to read and write the 
> config files. We have had certain ideas to use configparser and shlex 
> modules in it, but they tend to loose the comments so a solution needs 
> to be arrived at.

I still tend to use configparser and shlex - it's better (and hopefully 
faster) to improve them than to write something from scratch. A positive 
side effect will be that other users of those modules will also get the 
improvements.

In theory that means that you'll need to do the following changes in 
commentparser.py:
- in read(), store the comments somewhere[tm] instead of just stripping 
  them (note that it handles inline comments and full line comments in 
  different code blocks)
  If I had to write it, I'd make the "somewhere" inside self._sections 
  to store the comments and their location like
  - "at the beginning of the file"
  - "before "[foo]"
  - "before [foo] bar="
  - "at [foo]" (inline comment)
  - "at [foo] bar=" (inline comment)
  - "at the end of the file"
  Typically full line comments are above the line they describe, and 
  inline comments are (obviously) right of the setting they describe, so 
  that should be the way how you store the comment location.
- in write() and _write_section(), write the comments back at their
  original location (that's why you stored the location ;-)
  If the setting a comment was related to was removed, write it at the 
  the end of the section.

The changes to shlex should be even easier because shell-style config 
files are "flat" and don't have sections.

That said, if this turns out to be more difficult than I'm thinking ;-) 
I'll of course also accept a new module - but I'm quite sure that 
writing your own module will be more difficult than fixing the comment 
handling in the existing modules.


BTW: You'll need similar comment handling when reading, updating and 
writing profiles ;-)

> Work on the severity module which helps resolve the severity of 
> various accesses by the programs.

Yes, that's also a good starting point.

> Work on repository module.

The online profile repo is probably not the most urgent stuff ;-)

> Besides these, we also need to discuss whether notify module needs to 
> be done now or pushed until later, since it needs YCP. 

The notification/report stuff that was part of YaST is unmaintained 
since quite some time. Its replacement, aa-notify, does something 
similar (but not exactly the same) - but not integrated in YaST.

Besides that, the YaST team is moving away from YCP as programming 
language. (YCP is a language specific to YaST, and not many people 
understand it, which also means it's hard to find maintainers for YaST 
modules.)
They have a tool to (mostly) automatically convert YCP to ruby, but 
there are also YaST python bindings which might be a better choice in 
our case because we want to use the python libraries you'll write.

Anyway, I'd say we need a working base (python modules + commandline 
interface) first. When we have that, we can add the YaST user interface 
on top.


Regards,

Christian Boltz
-- 
[20:01] * mrdocs grabs a snack first
[20:01] <suseROCKs> hmm last time mrdocs said he was going to grab
        a snack, we didn't see him again for a week
[from #opensuse-project]