Re: [T(A)ILS-dev] GSoC application: tails-greeter

Delete this message

Reply to this message
Author: M
Date:  
To: intrigeri
CC: Damian Johnson, Tor Assistants, The T\(A\)ILS public development discussion list, tech
Subject: Re: [T(A)ILS-dev] GSoC application: tails-greeter
07.04.2011 17:33, intrigeri пишет:
> Your schedule seems a bit weird to me:
>   - the Community Bonding Period is not week #0, but a full month; I
>     guess you do know this, considering the amount of stuff you put in
>     there; but presenting it like this is at the very least surprising
>   - you only schedule 9 weeks, while the coding period covers 3
>     months; why?


Yeah, that's confusing - I've updated proposal with proper number of weeks and
description. Overall is 11 weeks, actual coding for me 10 weeks.

> Also, now that the raw content is ready, I think you should work a bit
> on the general organization of your proposal and on its markup, both
> of which being currently rather crude (there are still some questions
> text mixed with your answers in random order).


Oh crap - it looks ugly indeed - I'll try to make sense out of crappy text "editor"
in melange.

> To end with, there is the programming language choice thing:
>
>> - programming language (C if gdm-simple-greeter is forked\extended
>> or vala if tails-greeter is made from scratch)
>
> The choice of C if gdm-simple-greeter is forked/extended is obvious.
> The choice of Vala in case tails-greeter is written from scratch is
> not obvious to me. AFAIK you've not answered my previous questions [0]
> regarding this. Let me paste these (with quotes from you to provide
> the context) bellow again.


> I would be more comfortable to mentor your work if you chose Python.
> But if Vala seems much more appropriate to you, just use that. Why
> does is seem "the ideal variant" BTW?


Pretty much due to the reasons described in http://live.gnome.org/Vala/About :)
Also it looks like it will be more fun to work with.
Another thing - using pygtk add more maintenance burden: to track appropriate
version, to significantly change build process for gdm package (right now there is no
pyhton dependency). Of course it is possible but I do not see any "killer feature" in
python which will justify it.

> (Perl is the language I would be the most at ease to mentor.)
>
> What are the obstacles that prevent you from implementing
> tails-greeter in Perl? Missing bindings? Binding on CPAN but not in
> Debian? Other issues?
>
> I'd anyway be glad to see what kind of Perl you write; as you do know,
> there are plenty ;)


Attached is simple utility derived from some post on some forum.
It strips off what developers of Psi jabber client mistaken for encryption and
reveals plaintext saved passwords for all accounts.

Rather quick and dirty hack but works fine for me.

cheers,
Max.

#!/usr/bin/perl -w

use strict;
use English;
use XML::DOM::XPath;

print "info: $0 version 0.2 licensed under AGPLv3 or higher.\n";

my $tmp = "default";
my $target = "accounts.xml";

if(scalar @ARGV)
{
    $tmp = $ARGV[0];
    $target = $ARGV[1] if scalar @ARGV > 1;
    print "warning: too many arguments supplied - using \"$tmp\" as profile name, \"$target\" as filename and  ignoring the rest...\n" if scalar @ARGV > 2;
} else { print "info: no arguments given - assuming \"$tmp\" as profile name...\n"; }


my $jid = "$ENV{HOME}/.psi/profiles/$tmp/$target";
my $xml = XML::DOM::Parser->new->parsefile($jid) or die "error: unable to parse $jid\n";

print "info: removing stupid encoding from passwords stored in $jid...\n\n";

#my $nodes = '/psiconf/accounts/*'; # legacy psi versions
my $nodes = '/accounts/accounts/*';

for($xml->findnodes($nodes))
{
    my $passw  = $_->findnodes('password');
    $jid = $_->findnodes('jid');


    foreach($tmp = '', my ($n, @pw) = (0, split //, $passw); @pw; $n = $n >= length $passw ? 0 : $n)
    {
    $tmp .= chr((hex(shift @pw) * 4096 + hex(shift @pw) * 256 + hex(shift @pw) * 16 + hex(shift @pw)) ^ ord(substr $jid, $n++, 1));
    }


    print "$jid\t$tmp\n";
}


print "\ninfo: done.\n";