[freenet-dev] Promiscuous opennet

[Matthew Toseland]

On Tuesday 10 Apr 2012 19:32:20 Juiceman wrote:
> Should we do something about the amount of announcements/refs handed
> out?  Seems a good way to harvest opennet (known problem, but perhaps
> we could slow it down...) or perhaps monopolize/monitor the key-space
> somehow?

We could slow down path folding. But bootstrapping new nodes is hard enough 
already without slowing it down deliberately.

Just accept it, opennet is fundamentally insecure and unfixable. It sucks, it's 
a transitional phase.
> 
> opennetSizeEstimateSession: 18985 nodes
> opennetSizeEstimate24h:12435 nodes
> opennetSizeEstimate48h:14855 nodes
> nodeUptimeSession:   4d23h
> 
> 
> Seed stats
> IPConnected  Announced  Accepted  Completed  Sent
> refsVersion
> 24.126.77.671766352352352
>   5201406
> 202.134.203.35 1785279279279
>  1812  1377
> 213.134.163.3   1792275275275
>   1819  1388
> 68.227.101.68   1793293293293
>   1747  1389
> 62.107.42.7   1803257257257
> 1774  1389
> 67.61.122.2461840267267267
>1809 1397
> 82.66.7.51 1843247247247
>  1400  1397
> 78.105.55.2061846290290290
>2053  1388
> 68.144.7.7 1853438438438
>  1481406
> 80.217.175.104  1868314314314
>   2053  1388
> 67.169.243.331919317317317
>4161406
> 208.76.88.92  1939327327327
> 1980  1376
> 98.21.244.1131951317317317
>2238  1376
> 50.4.40.1461979308308308
>  2106  1385
> 71.204.143.231   2041292292292
>1629  1385
> 81.56.65.622043278278278
>  2209  1384
> 88.174.162.112   2071297297297
>2104  1378
> 88.90.64.247  2110278278278
> 1658  1397
> 88.172.49.91  2120305305305
> 1730  1372
> 69.228.173.126   2146318318318
>2247  1364
> 
> 
> --
> I may disagree with what you have to say, but I shall defend, to the
> death, your right to say it. - Voltaire
> Those who would give up Liberty, to purchase temporary Safety, deserve
> neither Liberty nor Safety. - Ben Franklin
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120412/60ec283a/attachment.pgp>

[freenet-dev] webui and accessibility

[Nicolas Hernandez]

- Nicolas Hernandez

> *
>> Concerning GWT*:
>> *If all devs and the leader of http://goo.gl/QhPVD are ok to use GWT *we
>> can consider rewriting FProxy using GWT components.
>> We can use GWT as a pool of components only.
>> -> Using Velocity for templating (if needed).
>> -> using jsp like pages
>>
>
> I'm not sure what you mean by "using JSP-like pages"? do you mean to
> imitate JSP-Behavior by utilizing Velocity? or to use VelocityStruts (
> https://velocity.apache.org/tools/devel/struts/) to support JSP pages?
>

Nope, a minimal standard application like jetty supports jsp pages.
Velocity can be use for site templating instead og GWT one.


>
> -> developping gwt components simply embeded into jsp pages (qwt with dual
>> mode js/non-js)
>>
>
> Is there anyway to avoid JavaScript when using GWT? If I'm not mistaken,
> the GWT compiler (or better said: translator) compiles Java to JavaScript (
> http://css.dzone.com/news/understanding-gwt-compiler). Are you going to
> another framework for non-JS support?
>
> Nope, je just have to extend GWT and override it if needed ... just
standard Object Coding :-)



>
>> ps: jsp pages are a good solution for designers (as wickets)
>>
>
> In deed! However there was a discussion last year regarding using JSP (
> http://www.mail-archive.com/devl at freenetproject.org/msg25805.html).
> Matthew was more or less against using JSP and Servlets, because of the
> extra features (and size!) which we don't need. That's why we moved to
> Velocity: simplicity, fast and small in size.
>
>>
>>
Yes  i know. But we are working about accessibility :-)  for
developpers too ! ;-)


   - Velocity for templating
   - html+jsp for site rendering
   - gwt+nonjs for components and components rendering

We can use struts+gwt components if you want, or other, struts is really
too complex in my opinion for fproxy.




> *
>> *
>> - Nicolas Hernandez
>> a-n - aleph-networks
>> *CEO*
>> http://www.aleph-networks.com
>>
>>
>>
>>
>>
>> On Wed, Apr 11, 2012 at 2:32 PM, Pouyan Zachar > gmail.com>wrote:
>>
>>> Dear Nicolas,
>>>
>>> as you may know, I have proposed to rewrite the Freenet GUI in context
>>> of GSoC 2012 (see http://goo.gl/kOEAU and http://goo.gl/QhPVD)  In
>>> order to avoid duplicate implementations, I would really like to get more
>>> insight about your current approach and implementation using GWT.
>>>
>>> Regards
>>> Pouyan
>>>
>>
>>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120412/6f4c0cec/attachment.html>

[freenet-dev] webui and accessibility

[Pouyan Zachar]

Hi!

On Thu, Apr 12, 2012 at 9:40 AM, Nicolas Hernandez <
nicolas.hernandez at aleph-networks.com> wrote:

> Hello,
> *First of all*;
>
>- http://goo.gl/kOEAU
>- http://goo.gl/QhPVD
>
> Are ok for me, the only reason i prefer going to gwt is the team. It is
> easier to find dev using GWT than Wickets.
> Wicket + Velocity is a excellent solution, if there is a team of minimum 5
> devs. We can help about these 2 projects (code review, architecture design,
> and some devs later)
>

Great to hear!

*
> Concerning GWT*:
> *If all devs and the leader of http://goo.gl/QhPVD are ok to use GWT *we
> can consider rewriting FProxy using GWT components.
> We can use GWT as a pool of components only.
> -> Using Velocity for templating (if needed).
> -> using jsp like pages
>

I'm not sure what you mean by "using JSP-like pages"? do you mean to
imitate JSP-Behavior by utilizing Velocity? or to use VelocityStruts (
https://velocity.apache.org/tools/devel/struts/) to support JSP pages?

-> developping gwt components simply embeded into jsp pages (qwt with dual
> mode js/non-js)
>

Is there anyway to avoid JavaScript when using GWT? If I'm not mistaken,
the GWT compiler (or better said: translator) compiles Java to JavaScript (
http://css.dzone.com/news/understanding-gwt-compiler). Are you going to
another framework for non-JS support?


> ps: jsp pages are a good solution for designers (as wickets)
>

In deed! However there was a discussion last year regarding using JSP (
http://www.mail-archive.com/devl at freenetproject.org/msg25805.html). Matthew
was more or less against using JSP and Servlets, because of the extra
features (and size!) which we don't need. That's why we moved to Velocity:
simplicity, fast and small in size.

>
>
> *Remember, we have solutions, but we are only followers. In all cases
> FProxy rewriting needs an afficial and hitorical dev leader (like nextgen
> :-) )*


Indeed!


> *
> *
> - Nicolas Hernandez
> a-n - aleph-networks
> *CEO*
> http://www.aleph-networks.com
>
>
>
>
>
> On Wed, Apr 11, 2012 at 2:32 PM, Pouyan Zachar wrote:
>
>> Dear Nicolas,
>>
>> as you may know, I have proposed to rewrite the Freenet GUI in context of
>> GSoC 2012 (see http://goo.gl/kOEAU and http://goo.gl/QhPVD)  In order to
>> avoid duplicate implementations, I would really like to get more insight
>> about your current approach and implementation using GWT.
>>
>> Regards
>> Pouyan
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120412/b04a0e5f/attachment.html>

[freenet-dev] Improving build security against back-doors: Bytecode verification

[Matthew Toseland]

On Thursday 12 Apr 2012 04:07:02 Zlatin Balevsky wrote:
> >
> > It appears we can just compare the bytecode however. If you want to compare 
> > the disassembly that's good too, but somebody should check the source.
> >
> > I have uploaded a basic version of a bytecode verification script called 
> > verify-build to the "Maintenance scripts" repository on github. 
> > Unfortunately build 1406 includes some classes that are only in my local 
> > tree because cleanup occurs a little too late. Anyway if you want to use 
> > it, or improve it, that would be cool.
> >
> > I have completed proof of concept (the bytecode is the same for two builds, 
> > including when doing a clean checkout in a separate folder). Provided that 
> > you use the same java compiler as the person doing the release, it should 
> > work (for 1407 onwards).
> 
> If at some point in the future the installers start using pack200 jar
> compression that may mangle the bytecode and would complicate the
> verification process as uncompressed .class files will be different
> than javac output.  If for whatever reason Freenet explodes in
> popularity overnight you may not have choice - pack200 is far cheaper
> than finding more hosting bandwidth.

As long as it is deterministic it can be verified by a third party. Also, 
Google Code is hardly likely to dump us, they must host much more popular 
projects, so download bandwidth is unlikely to be an issue.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120412/4dde0900/attachment.pgp>

[freenet-dev] Improving build security against back-doors: Bytecode verification

[Matthew Toseland]

On Wednesday 11 Apr 2012 23:21:40 Matthew Toseland wrote:
> On Wednesday 11 Apr 2012 00:58:49 Marco Schulze wrote:
> > Addendum: no remote fetching or tag validation. Downloading the jars and 
> > git repo can easily be done outside the script, and tag validation 
> > requires a bit of manual work (importing and setting key trust).
> 
> Nextgens is of the view that disassemblers can be fooled into not 
> disassembling certain stretches of code. (Source?)
> 
> It appears we can just compare the bytecode however. If you want to compare 
> the disassembly that's good too, but somebody should check the source.

Err I mean somebody should run the bytecode verification script. It's not ready 
for your crontab just yet though...
> 
> I have uploaded a basic version of a bytecode verification script called 
> verify-build to the "Maintenance scripts" repository on github. Unfortunately 
> build 1406 includes some classes that are only in my local tree because 
> cleanup occurs a little too late. Anyway if you want to use it, or improve 
> it, that would be cool.
> 
> I have completed proof of concept (the bytecode is the same for two builds, 
> including when doing a clean checkout in a separate folder). Provided that 
> you use the same java compiler as the person doing the release, it should 
> work (for 1407 onwards).
> 
> Want to play with it? Post pull requests for any improvements ... I *may* get 
> around to improving it further, there are some major deficiencies, the main 
> one being that it figures out the latest build from the repository, which 
> could be spoofed; it should check from auto-update or pick up the 
> announcement or something. (And compare it to the HTTPS jars of course)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120412/e42f4e39/attachment.pgp>

[freenet-dev] Improving build security against back-doors: Bytecode verification

[Matthew Toseland]

On Wednesday 11 Apr 2012 00:58:49 Marco Schulze wrote:
> Addendum: no remote fetching or tag validation. Downloading the jars and 
> git repo can easily be done outside the script, and tag validation 
> requires a bit of manual work (importing and setting key trust).

Nextgens is of the view that disassemblers can be fooled into not disassembling 
certain stretches of code. (Source?)

It appears we can just compare the bytecode however. If you want to compare the 
disassembly that's good too, but somebody should check the source.

I have uploaded a basic version of a bytecode verification script called 
verify-build to the "Maintenance scripts" repository on github. Unfortunately 
build 1406 includes some classes that are only in my local tree because cleanup 
occurs a little too late. Anyway if you want to use it, or improve it, that 
would be cool.

I have completed proof of concept (the bytecode is the same for two builds, 
including when doing a clean checkout in a separate folder). Provided that you 
use the same java compiler as the person doing the release, it should work (for 
1407 onwards).

Want to play with it? Post pull requests for any improvements ... I *may* get 
around to improving it further, there are some major deficiencies, the main one 
being that it figures out the latest build from the repository, which could be 
spoofed; it should check from auto-update or pick up the announcement or 
something. (And compare it to the HTTPS jars of course)
> 
> On 10-04-2012 20:51, Marco Schulze wrote:
> > Attached is a quick (and ugly) bash script which compares the 
> > disassembly of class files inside freenet.jar with the disassembly of 
> > class files compiled from the git repository. Because it uses javap, 
> > it's extremely slow.
> >
> > I'm running the script now, and so far it has found 8 class files with 
> > different bytecode. I don't know enough to tell why they differ, but 
> > my guess is that this is due to different compilers (official: JDK 
> > 1.6.0_26-b03, me: OpenJDK 1.7.0_03), or I screwed up somewhere...
> >
> > On 10-04-2012 16:01, Matthew Toseland wrote:
> >> We need a script that downloads the latest released jar, and fetches the 
> >> corresponding git tag, compiles the code, and compares it to what has been 
> >> released. Nextgens had a script doing something similar for a while to 
> >> check indenting changes; Java compilation to bytecode is deterministic, 
> >> but you can't just compare the jar's, you need to break out the class 
> >> files and then compare them. Whoever runs this (hopefully more than one 
> >> person) would need to have the same setup that builds are generated on. 
> >> When I release a build, I compile on my system, which is Debian stable. 
> >> The script could be totally automated with a little work (and would have 
> >> to be adjusted for releases by other people, but this is easily checked by 
> >> who signed the tag).
> >>
> >> Anyone want to write such a script? Nextgens do you have the old 
> >> whitespace change checker script still?
> >>
> >> I suspect we could get suitable volunteers fairly easily.
> >>
> >> IMHO it is important to have third party verification (with said third 
> >> parties not being connected to FPI and ideally some of them not being 
> >> traceable). For all we know my computer is backdoored and it's releasing 
> >> patched builds with surveillance addons already! And future laws, in the 
> >> UK and elsewhere, may compel developers to do this themselves, secretly.
> >>
> >> This should be relatively easy to implement, and should put a lot of 
> >> people's minds at rest. So anyone want to develop such a script?
> >>
> >>
> >> ___
> >> Devl mailing list
> >> Devl at freenetproject.org
> >> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Improving build security against back-doors: Bytecode verification

[Zlatin Balevsky]

>
> It appears we can just compare the bytecode however. If you want to compare 
> the disassembly that's good too, but somebody should check the source.
>
> I have uploaded a basic version of a bytecode verification script called 
> verify-build to the "Maintenance scripts" repository on github. Unfortunately 
> build 1406 includes some classes that are only in my local tree because 
> cleanup occurs a little too late. Anyway if you want to use it, or improve 
> it, that would be cool.
>
> I have completed proof of concept (the bytecode is the same for two builds, 
> including when doing a clean checkout in a separate folder). Provided that 
> you use the same java compiler as the person doing the release, it should 
> work (for 1407 onwards).

If at some point in the future the installers start using pack200 jar
compression that may mangle the bytecode and would complicate the
verification process as uncompressed .class files will be different
than javac output.  If for whatever reason Freenet explodes in
popularity overnight you may not have choice - pack200 is far cheaper
than finding more hosting bandwidth.

Re: [freenet-dev] Improving build security against back-doors: Bytecode verification

[Matthew Toseland]

On Thursday 12 Apr 2012 04:07:02 Zlatin Balevsky wrote:
 
  It appears we can just compare the bytecode however. If you want to compare 
  the disassembly that's good too, but somebody should check the source.
 
  I have uploaded a basic version of a bytecode verification script called 
  verify-build to the Maintenance scripts repository on github. 
  Unfortunately build 1406 includes some classes that are only in my local 
  tree because cleanup occurs a little too late. Anyway if you want to use 
  it, or improve it, that would be cool.
 
  I have completed proof of concept (the bytecode is the same for two builds, 
  including when doing a clean checkout in a separate folder). Provided that 
  you use the same java compiler as the person doing the release, it should 
  work (for 1407 onwards).
 
 If at some point in the future the installers start using pack200 jar
 compression that may mangle the bytecode and would complicate the
 verification process as uncompressed .class files will be different
 than javac output.  If for whatever reason Freenet explodes in
 popularity overnight you may not have choice - pack200 is far cheaper
 than finding more hosting bandwidth.

As long as it is deterministic it can be verified by a third party. Also, 
Google Code is hardly likely to dump us, they must host much more popular 
projects, so download bandwidth is unlikely to be an issue.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] webui and accessibility

[Pouyan Zachar]

Hi!

On Thu, Apr 12, 2012 at 9:40 AM, Nicolas Hernandez 
nicolas.hernan...@aleph-networks.com wrote:

 Hello,
 *First of all*;

- http://goo.gl/kOEAU
- http://goo.gl/QhPVD

 Are ok for me, the only reason i prefer going to gwt is the team. It is
 easier to find dev using GWT than Wickets.
 Wicket + Velocity is a excellent solution, if there is a team of minimum 5
 devs. We can help about these 2 projects (code review, architecture design,
 and some devs later)


Great to hear!

*
 Concerning GWT*:
 *If all devs and the leader of http://goo.gl/QhPVD are ok to use GWT *we
 can consider rewriting FProxy using GWT components.
 We can use GWT as a pool of components only.
 - Using Velocity for templating (if needed).
 - using jsp like pages


I'm not sure what you mean by using JSP-like pages? do you mean to
imitate JSP-Behavior by utilizing Velocity? or to use VelocityStruts (
https://velocity.apache.org/tools/devel/struts/) to support JSP pages?

- developping gwt components simply embeded into jsp pages (qwt with dual
 mode js/non-js)


Is there anyway to avoid JavaScript when using GWT? If I'm not mistaken,
the GWT compiler (or better said: translator) compiles Java to JavaScript (
http://css.dzone.com/news/understanding-gwt-compiler). Are you going to
another framework for non-JS support?


 ps: jsp pages are a good solution for designers (as wickets)


In deed! However there was a discussion last year regarding using JSP (
http://www.mail-archive.com/devl@freenetproject.org/msg25805.html). Matthew
was more or less against using JSP and Servlets, because of the extra
features (and size!) which we don't need. That's why we moved to Velocity:
simplicity, fast and small in size.



 *Remember, we have solutions, but we are only followers. In all cases
 FProxy rewriting needs an afficial and hitorical dev leader (like nextgen
 :-) )*


Indeed!


 *
 *
 - Nicolas Hernandez
 a-n - aleph-networks
 *CEO*
 http://www.aleph-networks.com





 On Wed, Apr 11, 2012 at 2:32 PM, Pouyan Zachar pouyans...@gmail.comwrote:

 Dear Nicolas,

 as you may know, I have proposed to rewrite the Freenet GUI in context of
 GSoC 2012 (see http://goo.gl/kOEAU and http://goo.gl/QhPVD)  In order to
 avoid duplicate implementations, I would really like to get more insight
 about your current approach and implementation using GWT.

 Regards
 Pouyan



___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] webui and accessibility

[Nicolas Hernandez]

- Nicolas Hernandez

 *
 Concerning GWT*:
 *If all devs and the leader of http://goo.gl/QhPVD are ok to use GWT *we
 can consider rewriting FProxy using GWT components.
 We can use GWT as a pool of components only.
 - Using Velocity for templating (if needed).
 - using jsp like pages


 I'm not sure what you mean by using JSP-like pages? do you mean to
 imitate JSP-Behavior by utilizing Velocity? or to use VelocityStruts (
 https://velocity.apache.org/tools/devel/struts/) to support JSP pages?


Nope, a minimal standard application like jetty supports jsp pages.
Velocity can be use for site templating instead og GWT one.



 - developping gwt components simply embeded into jsp pages (qwt with dual
 mode js/non-js)


 Is there anyway to avoid JavaScript when using GWT? If I'm not mistaken,
 the GWT compiler (or better said: translator) compiles Java to JavaScript (
 http://css.dzone.com/news/understanding-gwt-compiler). Are you going to
 another framework for non-JS support?

 Nope, je just have to extend GWT and override it if needed ... just
standard Object Coding :-)




 ps: jsp pages are a good solution for designers (as wickets)


 In deed! However there was a discussion last year regarding using JSP (
 http://www.mail-archive.com/devl@freenetproject.org/msg25805.html).
 Matthew was more or less against using JSP and Servlets, because of the
 extra features (and size!) which we don't need. That's why we moved to
 Velocity: simplicity, fast and small in size.



Yes  i know. But we are working about accessibility :-)  for
developpers too ! ;-)


   - Velocity for templating
   - html+jsp for site rendering
   - gwt+nonjs for components and components rendering

We can use struts+gwt components if you want, or other, struts is really
too complex in my opinion for fproxy.




 *
 *
 - Nicolas Hernandez
 a-n - aleph-networks
 *CEO*
 http://www.aleph-networks.com





 On Wed, Apr 11, 2012 at 2:32 PM, Pouyan Zachar pouyans...@gmail.comwrote:

 Dear Nicolas,

 as you may know, I have proposed to rewrite the Freenet GUI in context
 of GSoC 2012 (see http://goo.gl/kOEAU and http://goo.gl/QhPVD)  In
 order to avoid duplicate implementations, I would really like to get more
 insight about your current approach and implementation using GWT.

 Regards
 Pouyan




___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Promiscuous opennet

[Matthew Toseland]

On Tuesday 10 Apr 2012 19:32:20 Juiceman wrote:
 Should we do something about the amount of announcements/refs handed
 out?  Seems a good way to harvest opennet (known problem, but perhaps
 we could slow it down...) or perhaps monopolize/monitor the key-space
 somehow?

We could slow down path folding. But bootstrapping new nodes is hard enough 
already without slowing it down deliberately.

Just accept it, opennet is fundamentally insecure and unfixable. It sucks, it's 
a transitional phase.
 
 opennetSizeEstimateSession: 18985 nodes
 opennetSizeEstimate24h:12435 nodes
 opennetSizeEstimate48h:14855 nodes
 nodeUptimeSession:   4d23h
 
 
 Seed stats
 IPConnected  Announced  Accepted  Completed  Sent
 refsVersion
 24.126.77.671766352352352
   5201406
 202.134.203.35 1785279279279
  1812  1377
 213.134.163.3   1792275275275
   1819  1388
 68.227.101.68   1793293293293
   1747  1389
 62.107.42.7   1803257257257
 1774  1389
 67.61.122.2461840267267267
1809 1397
 82.66.7.51 1843247247247
  1400  1397
 78.105.55.2061846290290290
2053  1388
 68.144.7.7 1853438438438
  1481406
 80.217.175.104  1868314314314
   2053  1388
 67.169.243.331919317317317
4161406
 208.76.88.92  1939327327327
 1980  1376
 98.21.244.1131951317317317
2238  1376
 50.4.40.1461979308308308
  2106  1385
 71.204.143.231   2041292292292
1629  1385
 81.56.65.622043278278278
  2209  1384
 88.174.162.112   2071297297297
2104  1378
 88.90.64.247  2110278278278
 1658  1397
 88.172.49.91  2120305305305
 1730  1372
 69.228.173.126   2146318318318
2247  1364
 
 
 --
 I may disagree with what you have to say, but I shall defend, to the
 death, your right to say it. - Voltaire
 Those who would give up Liberty, to purchase temporary Safety, deserve
 neither Liberty nor Safety. - Ben Franklin
 ___
 Devl mailing list
 Devl@freenetproject.org
 https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl