pidgin-paranoia-devel Mailing List for Pidgin One-Time Pad Plug-in

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi *,

I added Gettext support (localization support) to the trunk. Please test
it and start translating the plug-in into every known language ;).

Cheers,
Simon

Hello

My code is ready. I have fixed the double 'encryption enabled' bug some
days ago. Some testing would be nice. The G_SIZE_FORMAT problem is fixed
in r379 (today).

All user visible strings are in the file paranoia.c. It would be nice if
you could read through it and create a diff of you suggestions. Very
similar strings should be unified, as it simplifies the translation.
Scattered strings are bad too. (e.g. paranoia.c line 570ff, r374)
So maybe some code changes are needed too. Strings printed by
purple_debug() won't be translated, but improvements are welcome.

I have not the time/motivation to do any code reviews at the moment.

But the documentation is severely outdated and needs to be updated
before release. (INSTALL, README, INFO...)

It would be nice if we could release this weekend! I will work on the
scattered strings and take a look at the documentation.

Cheers,
Simon

Christian Wäckerlin schrieb:
> Fellow developers,
>
> (when) are we ready to release?
>
> Regarding the string freeze, someone who is better than I in english told
> me that we have problems with the english grammatics.
> We should the user relevant strings carefully before string freeze.
>
> TODO 0.3 (as I see it)
> ------------------
>  * code review
>  * dokumentation
>  * AMD64, power testing
>   - gsize has the size of a pointer, so different format specifiers are
> requiered
>    - use G_GSIZE_FORMAT
> line 197:                 msg = g_strdup_printf("%s->%s (%s), %"
> G_GSIZE_FORMAT " Bytes\n\n"
>   - amd64: I tested 'otptester --genusekey' so far and this works
>  * there are a few strings in the code that should be replaced with
> constants,
>   - i.e. 'entropy'
>  * analize strings --> string freeze
>   - english grammar is wrong (janne)
>
> Greetings
>
> Christian
>
> "Freedom is being able to make decisions that affect mainly you. Power
> is being able to make decisions that affect others more than you. If we
> confuse power with freedom, we will fail to uphold real freedom." --
> Richard M. Stallman
>
>
>
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pidgin-paranoia-devel mailing list
> Pid...@li...
> https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel
>   

Hello developers 

Considering the TODO list I think my code is ready for the release.
First of all, I do not have any user relevant strings in my code. I
think it's not necessary to translate the error messages in my code. So
I don't see any reason to do a string freeze in my code at the moment.
I know, that my error messages are maybe sometimes a little weird
concerning the english grammar, but I think that I will do a review for
the 0.4 version, when I anyway will concentrate on minor issues.

I don't know what you exactly want to say with the gsize stuff, but I
think it's not a problem in my code.

I try to help with the string analyzing and the whole english stuff, but
actually my passive english is much better then the active one.
Furthermore I can't even write correct sentences in german, so it might
be better if I only search for errors and weird stuff, then actually
correcting them.

Cheers
Pasci

Fellow developers,

(when) are we ready to release?

Regarding the string freeze, someone who is better than I in english told
me that we have problems with the english grammatics.
We should the user relevant strings carefully before string freeze.

TODO 0.3 (as I see it)
------------------
 * code review
 * dokumentation
 * AMD64, power testing
  - gsize has the size of a pointer, so different format specifiers are
requiered
   - use G_GSIZE_FORMAT
line 197:                 msg = g_strdup_printf("%s->%s (%s), %"
G_GSIZE_FORMAT " Bytes\n\n"
  - amd64: I tested 'otptester --genusekey' so far and this works
 * there are a few strings in the code that should be replaced with
constants,
  - i.e. 'entropy'
 * analize strings --> string freeze
  - english grammar is wrong (janne)

Greetings

Christian

"Freedom is being able to make decisions that affect mainly you. Power
is being able to make decisions that affect others more than you. If we
confuse power with freedom, we will fail to uphold real freedom." --
Richard M. Stallman

The keygen_anhancement branch has been merged and deleted. There were no
collisions.

I renamed the keygen signal from "keygen_key_done_signal" to
"keygen-status-update" as it reflects more was it actually does.

Cheers
Simon

Hi

Today I commited several new features to the trunk. A new key management
API, move-to-front transform in the key list, a pop-up after key
generation and the possibility to show status reports in the
conversation while generating a key (not used yet). Please test these
features, regressions are very likely. After these changes, it's a good
time to merge your branches. If you want to merge please get in touch
with me.

btw: Pidgin 2.5.0 was released some days ago.

Cheers,
Simon

Hi Chri

While testing my changes for the keygen I discovered a small memory leak
in libotp.c:otp_decrypt around line 787
You allocate memory with the strdup function in this line:
gsize testpos = g_ascii_strtoull( strdup(m_array[0]), NULL, 10);

But you because you don't use a variable you are not able to free that
memory again and so at every decryption some bytes are lost.

Cheers, Pasci

Well, there are other issues. If pidgin crashed while creating a key,
you end up with invalid keys that get loaded at the next start. The same
happens if the user restarts pidgin or reloads the plugin.

But your solution sounds good.

Greetings,
Simon

Pascal Sachs schrieb:
> Hi,
>
> how would be the solution to just rename the .entropy extension to .tmp
> during the key generation. If the plugin just searches for .entropy
> files as I suggest, it would be the easiest solution for that problem
> and makes the whole generation stuff more transparent if we would accept
> multiple key generations at the same time in later versions for debuging
> purposes. 
> But anyway I wouldn't think of a work around for version 0.2.0 if
> the /otp scan feature isn't available anyway, because I would then just
> generate dirty code for no reason.
>
> Pascal
>
> Am Mittwoch, den 27.02.2008, 23:56 +0100 schrieb Christian Wäckerlin:
>   
>> Hi,
>>
>> I agree completely. I could live without /otp scan in 0.2 but if its
>> done soon it's ok as well.
>>
>> Can you do this workaround with the key named something like
>> generating-3F2DDDD.tmp during keygen?
>> I agree with Simon that the current state is quite confusing.
>>
>> Btw: I will code something like "./otptester --check-many-things" to
>> help finding avoidable (rare) errors and regressions for 0.2 this WE.
>>
>> Cheers
>>
>> Chri
>>
>> Pascal Sachs schrieb:
>>     
>>> Hi to everyone
>>>
>>> I think we should delay the whole otp scan, pad initalization and
>>> signaling stuff to version 0.3.0 because it looks, like this will create
>>> a lot of work for all of us and would therefore delay the 0.2.0 version
>>> to much. Furthermore I think it is not that important to have all this
>>> features in that early state of development, because the main
>>> functionality of our plugin is already working and the software is still
>>> in alpha, so we don't have to provide all the stuff now. I think it's
>>> also fun for our community to get more features in every version rather
>>> then just bugfixes and optimization stuff.
>>>
>>> Cheers,
>>> Pascal
>>>    
>>>   
>>>       
>>>> Ok, thanks.
>>>>  
>>>> I realised, that the pad struct stuff does not make sense, because when
>>>> the keygen function returns it has only initialised the creation and no
>>>> keys are generated yet. These pads have to be set with the "finished"
>>>> signal. So we should delay that feature for 0.3.0 too.
>>>>
>>>> I have planed to create an '/otp scan' command (in 0.2.0), but that
>>>> currently leads to problems when a key is being created in parallel. A
>>>> broken key would be loaded. To fix that, the key generator should use a
>>>> random filename while collecting entropy and rename the file on completion.
>>>>
>>>> Cheers
>>>> Simon
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Pidgin-paranoia-devel mailing list
>>>> Pid...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel
>>>>     
>>>> ------------------------------------------------------------------------
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Pidgin-paranoia-devel mailing list
>>>> Pid...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel
>>>>     
>>>>         
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________ Pidgin-paranoia-devel mailing list Pid...@li... https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel
>>     
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Pidgin-paranoia-devel mailing list
>> Pid...@li...
>> https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel
>>     

Hello

I agree with both of you, we should stop adding new features to 0.2.

But in my opinion some stuff needs to be fixed/done:
 * ~/.paranoia has to be created if not available.
 * The key file has to be created after all entropy has been collected.
Otherwise, there is no way a user can find out, that the key generation
has completed in 0.2.
 * More testing. We have to test multiple keys per user and small keys
that finish, possible errors and other corner cases.

Cheers,
Simon

PS: Currently I have some problems sending mails to this mailinglist.
The last message you received from me was written several days ago. :-/

Christian Wäckerlin schrieb:
> hi there!
>
> What do you think about releasing 0.2 soon?
>
> About the features of 0.2.0:
>
> * Regarding the libotp part there is only this check for 'patterns' /
> 'improbabilities' in the keys.
> The function and everything is done since 0.1 but the math/statistics is
> missing.
> The problem is to know the probability of a repeat with a certain length
> in a random char* of a certrain length.
> If this is VERY unlikely (i.e. 10^-12), one can assume that the key is
> not random.
>
> But anyway; i would propose to postpone it for a later release, ok?
>
> * Can we change the version of trunk to x.y.99?
>
> * Btw.: there is a bug in rev. 267: if the folder .paranoia does not
> exist, it will not be created. (Everything else worked. (-;)
> I will fix this. I think it would be best to do this on initialization
> of the plugin.
>
> Greetings,
>
> Chri
>
>
>
>
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pidgin-paranoia-devel mailing list
> Pid...@li...
> https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel
>   

Hi,

how would be the solution to just rename the .entropy extension to .tmp
during the key generation. If the plugin just searches for .entropy
files as I suggest, it would be the easiest solution for that problem
and makes the whole generation stuff more transparent if we would accept
multiple key generations at the same time in later versions for debuging
purposes. 
But anyway I wouldn't think of a work around for version 0.2.0 if
the /otp scan feature isn't available anyway, because I would then just
generate dirty code for no reason.

Pascal

Am Mittwoch, den 27.02.2008, 23:56 +0100 schrieb Christian Wäckerlin:
> Hi,
> 
> I agree completely. I could live without /otp scan in 0.2 but if its
> done soon it's ok as well.
> 
> Can you do this workaround with the key named something like
> generating-3F2DDDD.tmp during keygen?
> I agree with Simon that the current state is quite confusing.
> 
> Btw: I will code something like "./otptester --check-many-things" to
> help finding avoidable (rare) errors and regressions for 0.2 this WE.
> 
> Cheers
> 
> Chri
> 
> Pascal Sachs schrieb:
> > Hi to everyone
> >
> > I think we should delay the whole otp scan, pad initalization and
> > signaling stuff to version 0.3.0 because it looks, like this will create
> > a lot of work for all of us and would therefore delay the 0.2.0 version
> > to much. Furthermore I think it is not that important to have all this
> > features in that early state of development, because the main
> > functionality of our plugin is already working and the software is still
> > in alpha, so we don't have to provide all the stuff now. I think it's
> > also fun for our community to get more features in every version rather
> > then just bugfixes and optimization stuff.
> >
> > Cheers,
> > Pascal
> >    
> >   
> >> Ok, thanks.
> >>  
> >> I realised, that the pad struct stuff does not make sense, because when
> >> the keygen function returns it has only initialised the creation and no
> >> keys are generated yet. These pads have to be set with the "finished"
> >> signal. So we should delay that feature for 0.3.0 too.
> >>
> >> I have planed to create an '/otp scan' command (in 0.2.0), but that
> >> currently leads to problems when a key is being created in parallel. A
> >> broken key would be loaded. To fix that, the key generator should use a
> >> random filename while collecting entropy and rename the file on completion.
> >>
> >> Cheers
> >> Simon
> >>
> >>
> >> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Pidgin-paranoia-devel mailing list
> >> Pid...@li...
> >> https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel
> >>     
> >> ------------------------------------------------------------------------
> >>
> >> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Pidgin-paranoia-devel mailing list
> >> Pid...@li...
> >> https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel
> >>     
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________ Pidgin-paranoia-devel mailing list Pid...@li... https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel

Hi,

I agree completely. I could live without /otp scan in 0.2 but if its
done soon it's ok as well.

Can you do this workaround with the key named something like
generating-3F2DDDD.tmp during keygen?
I agree with Simon that the current state is quite confusing.

Btw: I will code something like "./otptester --check-many-things" to
help finding avoidable (rare) errors and regressions for 0.2 this WE.

Cheers

Chri

Pascal Sachs schrieb:
> Hi to everyone
>
> I think we should delay the whole otp scan, pad initalization and
> signaling stuff to version 0.3.0 because it looks, like this will create
> a lot of work for all of us and would therefore delay the 0.2.0 version
> to much. Furthermore I think it is not that important to have all this
> features in that early state of development, because the main
> functionality of our plugin is already working and the software is still
> in alpha, so we don't have to provide all the stuff now. I think it's
> also fun for our community to get more features in every version rather
> then just bugfixes and optimization stuff.
>
> Cheers,
> Pascal
>    
>   
>> Ok, thanks.
>>  
>> I realised, that the pad struct stuff does not make sense, because when
>> the keygen function returns it has only initialised the creation and no
>> keys are generated yet. These pads have to be set with the "finished"
>> signal. So we should delay that feature for 0.3.0 too.
>>
>> I have planed to create an '/otp scan' command (in 0.2.0), but that
>> currently leads to problems when a key is being created in parallel. A
>> broken key would be loaded. To fix that, the key generator should use a
>> random filename while collecting entropy and rename the file on completion.
>>
>> Cheers
>> Simon
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Pidgin-paranoia-devel mailing list
>> Pid...@li...
>> https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel
>>     
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Pidgin-paranoia-devel mailing list
>> Pid...@li...
>> https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel
>>     

Hi to everyone

I think we should delay the whole otp scan, pad initalization and
signaling stuff to version 0.3.0 because it looks, like this will create
a lot of work for all of us and would therefore delay the 0.2.0 version
to much. Furthermore I think it is not that important to have all this
features in that early state of development, because the main
functionality of our plugin is already working and the software is still
in alpha, so we don't have to provide all the stuff now. I think it's
also fun for our community to get more features in every version rather
then just bugfixes and optimization stuff.

Cheers,
Pascal

> Ok, thanks.
>  
> I realised, that the pad struct stuff does not make sense, because when
> the keygen function returns it has only initialised the creation and no
> keys are generated yet. These pads have to be set with the "finished"
> signal. So we should delay that feature for 0.3.0 too.
> 
> I have planed to create an '/otp scan' command (in 0.2.0), but that
> currently leads to problems when a key is being created in parallel. A
> broken key would be loaded. To fix that, the key generator should use a
> random filename while collecting entropy and rename the file on completion.
> 
> Cheers
> Simon
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pidgin-paranoia-devel mailing list
> Pid...@li...
> https://lists.sourceforge.net/lists/listinfo/pidgin-paranoia-devel

Pascal Sachs schrieb:
> my answers to de keygen stuff:
>
> * the keygen_integration branch is no longer needed so it can be
> deleted.
> * In 0.2.0 the key generation has following features:
> 	- One can generate max one key on the same time
> 	- Keys can be generated by the integrated keygen (no arguments), out of
> a file or out of a character device.
> 	- loop keys are supported
> * I would do the signaling stuff for version 0.3.0 or maybe later to
> 0.2.x, because it may cause some problems and affects the stability
> because I don't have much experience with signaling yet.
> * I will add the struct stuff this weekend so Simon can add new keys to
> the list. I will also check the new code of chris in my files and do a
> small clean up of my code.
>
> Cheers,
> Pascal
>   
Ok, thanks.

I realised, that the pad struct stuff does not make sense, because when
the keygen function returns it has only initialised the creation and no
keys are generated yet. These pads have to be set with the "finished"
signal. So we should delay that feature for 0.3.0 too.

I have planed to create an '/otp scan' command (in 0.2.0), but that
currently leads to problems when a key is being created in parallel. A
broken key would be loaded. To fix that, the key generator should use a
random filename while collecting entropy and rename the file on completion.

Cheers
Simon

hi there!

What do you think about releasing 0.2 soon?

About the features of 0.2.0:

* Regarding the libotp part there is only this check for 'patterns' /
'improbabilities' in the keys.
The function and everything is done since 0.1 but the math/statistics is
missing.
The problem is to know the probability of a repeat with a certain length
in a random char* of a certrain length.
If this is VERY unlikely (i.e. 10^-12), one can assume that the key is
not random.

But anyway; i would propose to postpone it for a later release, ok?

* Can we change the version of trunk to x.y.99?

* Btw.: there is a bug in rev. 267: if the folder .paranoia does not
exist, it will not be created. (Everything else worked. (-;)
I will fix this. I think it would be best to do this on initialization
of the plugin.

Greetings,

Chri

Pascal Sachs schrieb:
> my answers to de keygen stuff:
>
> * the keygen_integration branch is no longer needed so it can be
> deleted.
> * In 0.2.0 the key generation has following features:
> 	- One can generate max one key on the same time
> 	- Keys can be generated by the integrated keygen (no arguments), out of
> a file or out of a character device.
> 	- loop keys are supported
> * I would do the signaling stuff for version 0.3.0 or maybe later to
> 0.2.x, because it may cause some problems and affects the stability
> because I don't have much experience with signaling yet.
> * I will add the struct stuff this weekend so Simon can add new keys to
> the list. I will also check the new code of chris in my files and do a
> small clean up of my code.
>
> Cheers,
> Pascal
>   
Ok, thanks.

I realised, that the pad struct stuff does not make sense, because when
the keygen function returns it has only initialised the creation and no
keys are generated yet. These pads have to be set with the "finished"
signal. So we should delay that feature for 0.3.0 too.

I have planed to create an '/otp scan' command (in 0.2.0), but that
currently leads to problems when a key is being created in parallel. A
broken key would be loaded. To fix that, the key generator should use a
random filename while collecting entropy and rename the file on completion.

Cheers
Simon

my answers to de keygen stuff:

* the keygen_integration branch is no longer needed so it can be
deleted.
* In 0.2.0 the key generation has following features:
	- One can generate max one key on the same time
	- Keys can be generated by the integrated keygen (no arguments), out of
a file or out of a character device.
	- loop keys are supported
* I would do the signaling stuff for version 0.3.0 or maybe later to
0.2.x, because it may cause some problems and affects the stability
because I don't have much experience with signaling yet.
* I will add the struct stuff this weekend so Simon can add new keys to
the list. I will also check the new code of chris in my files and do a
small clean up of my code.

Cheers,
Pascal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Welcome to the pidgin-paranoia public developer mailing list!

Please send future project decisions and ongoing stuff to this list
(in English), so the project gets more transparent. Thanks.

Some questions:

* Can I delete the keygen_integration branche?
* What features should be part of 0.2.0? Especially keygen features.
(Please update TODO)
* Can someone add a struct pad* creation to the keygen? So I can add
new keys to the key list.

Thanks,
Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHveXP7ycmeUok62kRAiZkAJsHMtT5wbS4lN6eWayPxyZKmTO95wCffO84
ArINBSLVzNWfpheHQhe8hFg=
=MywI
-----END PGP SIGNATURE-----

pidgin-paranoia-devel Mailing List for Pidgin One-Time Pad Plug-in

pidgin-paranoia-devel — Pidgin-Paranoia Developers List