On Sat, Aug 06, 2011 at 12:38:24AM +0800, † wrote:
> 05.08.2011 23:25, bertagaz@??? пишет:
>
> > As I understood, you were also supposed to upload a Debian package to your
> > tails repo, which I can't find.
>
> Sorry, forgot to push it.
> Should be available now.
Seems not really, can't find any new commit with the new Debian package.
> > Seems like intrigeri already proposed a workaround to this last week,
> > please read again his answer to your report last week.
>
> Just to get potential readers up-to-date: the idea is following tails-greeter writes
> some instructions (env. variables, locale generation parameters smth else) to the
> place writable for it's user ("Debian-gdm") for example. Upon logon some startup
> script parse this file and execute them (as "amnesia" user or as root).
>
> That'll be next thing I'll try to implement and that's actually what I'd like to discuss:
So that maybe should be added to your schedule for next week, it was my
suggestion in my last email.
> - how good\safe is this approach?
Using such tricks to have something executed by root might sure bring the
question, and that's nice it pops up in your head. But well, we're talking
about mostly predefined choices, and run once during the system boot time.
I'm not sure to see what an attacker could do to take advantage of this
and s/he is able to do this, s/he can do a lot more.
> - are there better alternatives?
I'm out of idea for the moment, but will sleep on this.
> Note that at least some of the instructions from this file got to be executed with
> root privileges. Just to clarify: by " executed" I don't mean "sh file.sh" - it might
> be $ARG1 supplied to "sudo ls $ARG1".
>
> > Do you have pointers to this conversation? I might be interested to follow
> > it, and eventually help you with it.
>
> http://mail.gnome.org/archives/gdm-list/2011-August/msg00002.html
Thanks. Looks like for the moment they don't really have answers to your
issue, we'll see in the next days, but I suspect you won't have much
choices.
> >> replace 2 widgets with 1 panel with same functionality
> >> test the result with tails
> >
> > Sounds to me that the next step to this dev would be to implement a way to
> > pass env variables too.
>
> Not really sure what you mean. If you're talking about task priorities than - yes,
> that's true. The tasks are orthogonal though.
I meant: add to the next week plan the work on implementing a way to pass
env variables to the session.
I'm not sure to get why this two tasks are orthogonal, I rather feel that
the env thing is not that much related to how the widget/panel are
organized and can be developed independently from the other one. But
maybe I'm wrong and missing the big picture, and would be glad to have
your input in this case.
It seems that there is not much time left before the end of your GSOC, and
this is a critical piece of the project I'd like to see getting forward.
I'm not asking for this task to be completely done at the end of next
week, but given the time spent on the GSOC your commits seems to reveal,
I'd prefer to see some work going on in this area, and the plan you posted
initially might have some room left to add it.
But sure the panel reorganisation is also important. :)
> > Another question: reading your commits, you removed the babel module
> > importation. Do you plan to put it back, or are you just getting rid of
> > it? In the latter case, you should also consider removing it from the
> > install dependencies of the Debian package in debian/control.
>
> That was just part of pylint warnings cleanup.
> I didn't notice that it's completely gone now :)
Great!
bert.
