[freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Matthew Toseland
On Saturday 24 January 2009 18:18, Dennis Nezic wrote:
> On Sat, 24 Jan 2009 18:07:24 +, Matthew Toseland wrote:
> > fproxy can still be probed for, just not individual sites... We
> > should also warn about it in the README...
> 
> You mean the executable/jar can still be probed for on the filesystem?
> Maybe. But it can't be done via the network interface, if that iptables
> rule is in place--the port would appear as dead as any other unused
> port, as far as anyone except freenetuid would know.

I mean javascript port scanning. But yes you can do it with iptables rules.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 



[freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Matthew Toseland
On Saturday 24 January 2009 17:41, Dennis Nezic wrote:
> On Sat, 24 Jan 2009 13:05:41 +, Matthew Toseland wrote:
> > There have been some question marks over whether it is possible to
> > load an image from an external domain and get a callback when it is
> > loaded - if so, it may be possible to time fetches of specific sites
> > from javascript on an unrelated site. Meaning running a web browser
> > on a system with access to fproxy is dangerous. I haven't tested
> > this, maybe you'd like to?
> 
> It's a well known attack--"cache timing attacks". Pretty similar to
> css-history attacks. And it's also not hard to prevent. (For history
> attacks, simply disable history in your freenet profile.) For cache
> attacks, simply restrict access to fproxy to a separate freenet user on
> your system. (And, of course, do not use that user to surf the
> dangerous web--unless, of course, you use a safe browser, like one with
> javascript disabled. Javascript is, after all, the root of all
> (website) evil.)

The cross-domain rules don't prevent it then?
> 
> Fproxy access can be restricted on a per-user basis very simply with
> iptables:
> 
> iptables -A OUTPUT -p tcp --dport  -m owner ! --uid-owner
> $FREENETUID -j DROP

We have different definitions of easy! This is a good reason IMHO to not 
include fproxy by default once we have a dedicated browser. And even if we do 
that, fproxy can still be probed for, just not individual sites... We should 
also warn about it in the README...
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 



[freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Dennis Nezic
On Sat, 24 Jan 2009 18:07:24 +, Matthew Toseland wrote:
> fproxy can still be probed for, just not individual sites... We
> should also warn about it in the README...

You mean the executable/jar can still be probed for on the filesystem?
Maybe. But it can't be done via the network interface, if that iptables
rule is in place--the port would appear as dead as any other unused
port, as far as anyone except freenetuid would know.



[freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Matthew Toseland
On Friday 23 January 2009 01:53, [Anon] Anon User > wrote:
> -BEGIN TYPE III ANONYMOUS MESSAGE-
> Message-type: plaintext
> 
> In  Matthew Toseland  wrote:
> 
> >>> > > The real solution to browser history stealing is simply to use a 
separate
> >>> > > browser for Freenet than the one you use for the wider web. We now 
warn 
> > users
> >>> > > about this at the beginning of the first time wizard.
> >> > 
> >> > ^^ That is one more reason for the suggestion of a separate UI that I
> >> > made on freenet.uservoice.com. 
> > 
> > This is now largely accepted in the development team as a long-term goal. 
> > saces is working on something like this based on wxWindows. However, a 
> > dedicated browser/client (somewhere in between probably, e.g. there is no 
> > point in converting all the config pages to tabbed dialogs) would likely 
be a 
> > significant amount of work and require a significant amount of 
maintenance. 
> > So it's not a priority for 0.8.0.
> 
> I hope that as Freenet moves to this new UI, somewhere in the days 0.8+++, 
that
> plain old browser support is not discontinued.  There's plenty of us who 
know how
> to be secure with a browser and don't mind doing things like using a 
separate
> profile for the purpose with tighter settings.

And with various "features" turned off, and with lots of connections enabled, 
and so on.

There have been some question marks over whether it is possible to load an 
image from an external domain and get a callback when it is loaded - if so, 
it may be possible to time fetches of specific sites from javascript on an 
unrelated site. Meaning running a web browser on a system with access to 
fproxy is dangerous. I haven't tested this, maybe you'd like to?
> 
> I think there's a lot of use who prefer to stay with that functionality 
rather
> than a shiny new whiz-bang UI.

Fproxy will still be available as a plugin in any case.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 



[freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Dennis Nezic
On Sat, 24 Jan 2009 13:05:41 +, Matthew Toseland wrote:
> Meaning running a web browser on a system with access to fproxy is
> dangerous. I haven't tested this, maybe you'd like to?

I would imagine that the same problem exists on a system with access to
fcp? or telnet if it's enabled? Ie. aren't flash/javascript/
java/insert-evil-scripting-that-doesn't-belong-in-a-document capable
of issuing commands to fcp/telnet?

In which case, the same solution would trivially fix it.

Unless some kind of login-mechanism is implemented in all vectors to
freenet.



[freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Dennis Nezic
On Sat, 24 Jan 2009 13:05:41 +, Matthew Toseland wrote:
> There have been some question marks over whether it is possible to
> load an image from an external domain and get a callback when it is
> loaded - if so, it may be possible to time fetches of specific sites
> from javascript on an unrelated site. Meaning running a web browser
> on a system with access to fproxy is dangerous. I haven't tested
> this, maybe you'd like to?

It's a well known attack--"cache timing attacks". Pretty similar to
css-history attacks. And it's also not hard to prevent. (For history
attacks, simply disable history in your freenet profile.) For cache
attacks, simply restrict access to fproxy to a separate freenet user on
your system. (And, of course, do not use that user to surf the
dangerous web--unless, of course, you use a safe browser, like one with
javascript disabled. Javascript is, after all, the root of all
(website) evil.)

Fproxy access can be restricted on a per-user basis very simply with
iptables:

iptables -A OUTPUT -p tcp --dport  -m owner ! --uid-owner
$FREENETUID -j DROP



Re: [freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread [Anon] Anon User
-BEGIN TYPE III ANONYMOUS MESSAGE-
Message-type: plaintext

In  Matthew Toseland t...@amphibian.dyndns.org wrote:

   The real solution to browser history stealing is simply to use a 
   separate
   browser for Freenet than the one you use for the wider web. We now warn 
 users
   about this at the beginning of the first time wizard.
  
  ^^ That is one more reason for the suggestion of a separate UI that I
  made on freenet.uservoice.com. 
 
 This is now largely accepted in the development team as a long-term goal. 
 saces is working on something like this based on wxWindows. However, a 
 dedicated browser/client (somewhere in between probably, e.g. there is no 
 point in converting all the config pages to tabbed dialogs) would likely be a 
 significant amount of work and require a significant amount of maintenance. 
 So it's not a priority for 0.8.0.

I hope that as Freenet moves to this new UI, somewhere in the days 0.8+++, that
plain old browser support is not discontinued.  There's plenty of us who know 
how
to be secure with a browser and don't mind doing things like using a separate
profile for the purpose with tighter settings.

I think there's a lot of use who prefer to stay with that functionality rather
than a shiny new whiz-bang UI.


-END TYPE III ANONYMOUS MESSAGE-
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Matthew Toseland
On Friday 23 January 2009 01:53, [Anon] Anon User  wrote:
 -BEGIN TYPE III ANONYMOUS MESSAGE-
 Message-type: plaintext
 
 In  Matthew Toseland t...@amphibian.dyndns.org wrote:
 
The real solution to browser history stealing is simply to use a 
separate
browser for Freenet than the one you use for the wider web. We now 
warn 
  users
about this at the beginning of the first time wizard.
   
   ^^ That is one more reason for the suggestion of a separate UI that I
   made on freenet.uservoice.com. 
  
  This is now largely accepted in the development team as a long-term goal. 
  saces is working on something like this based on wxWindows. However, a 
  dedicated browser/client (somewhere in between probably, e.g. there is no 
  point in converting all the config pages to tabbed dialogs) would likely 
be a 
  significant amount of work and require a significant amount of 
maintenance. 
  So it's not a priority for 0.8.0.
 
 I hope that as Freenet moves to this new UI, somewhere in the days 0.8+++, 
that
 plain old browser support is not discontinued.  There's plenty of us who 
know how
 to be secure with a browser and don't mind doing things like using a 
separate
 profile for the purpose with tighter settings.

And with various features turned off, and with lots of connections enabled, 
and so on.

There have been some question marks over whether it is possible to load an 
image from an external domain and get a callback when it is loaded - if so, 
it may be possible to time fetches of specific sites from javascript on an 
unrelated site. Meaning running a web browser on a system with access to 
fproxy is dangerous. I haven't tested this, maybe you'd like to?
 
 I think there's a lot of use who prefer to stay with that functionality 
rather
 than a shiny new whiz-bang UI.

Fproxy will still be available as a plugin in any case.


pgp57uE7WFSp8.pgp
Description: PGP signature
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

Re: [freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Dennis Nezic
On Sat, 24 Jan 2009 13:05:41 +, Matthew Toseland wrote:
 There have been some question marks over whether it is possible to
 load an image from an external domain and get a callback when it is
 loaded - if so, it may be possible to time fetches of specific sites
 from javascript on an unrelated site. Meaning running a web browser
 on a system with access to fproxy is dangerous. I haven't tested
 this, maybe you'd like to?

It's a well known attack--cache timing attacks. Pretty similar to
css-history attacks. And it's also not hard to prevent. (For history
attacks, simply disable history in your freenet profile.) For cache
attacks, simply restrict access to fproxy to a separate freenet user on
your system. (And, of course, do not use that user to surf the
dangerous web--unless, of course, you use a safe browser, like one with
javascript disabled. Javascript is, after all, the root of all
(website) evil.)

Fproxy access can be restricted on a per-user basis very simply with
iptables:

iptables -A OUTPUT -p tcp --dport  -m owner ! --uid-owner
$FREENETUID -j DROP
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Dennis Nezic
On Sat, 24 Jan 2009 13:05:41 +, Matthew Toseland wrote:
 Meaning running a web browser on a system with access to fproxy is
 dangerous. I haven't tested this, maybe you'd like to?

I would imagine that the same problem exists on a system with access to
fcp? or telnet if it's enabled? Ie. aren't flash/javascript/
java/insert-evil-scripting-that-doesn't-belong-in-a-document capable
of issuing commands to fcp/telnet?

In which case, the same solution would trivially fix it.

Unless some kind of login-mechanism is implemented in all vectors to
freenet.
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Matthew Toseland
On Saturday 24 January 2009 17:41, Dennis Nezic wrote:
 On Sat, 24 Jan 2009 13:05:41 +, Matthew Toseland wrote:
  There have been some question marks over whether it is possible to
  load an image from an external domain and get a callback when it is
  loaded - if so, it may be possible to time fetches of specific sites
  from javascript on an unrelated site. Meaning running a web browser
  on a system with access to fproxy is dangerous. I haven't tested
  this, maybe you'd like to?
 
 It's a well known attack--cache timing attacks. Pretty similar to
 css-history attacks. And it's also not hard to prevent. (For history
 attacks, simply disable history in your freenet profile.) For cache
 attacks, simply restrict access to fproxy to a separate freenet user on
 your system. (And, of course, do not use that user to surf the
 dangerous web--unless, of course, you use a safe browser, like one with
 javascript disabled. Javascript is, after all, the root of all
 (website) evil.)

The cross-domain rules don't prevent it then?
 
 Fproxy access can be restricted on a per-user basis very simply with
 iptables:
 
 iptables -A OUTPUT -p tcp --dport  -m owner ! --uid-owner
 $FREENETUID -j DROP

We have different definitions of easy! This is a good reason IMHO to not 
include fproxy by default once we have a dedicated browser. And even if we do 
that, fproxy can still be probed for, just not individual sites... We should 
also warn about it in the README...


pgpjFCgOV4uVo.pgp
Description: PGP signature
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

Re: [freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Dennis Nezic
On Sat, 24 Jan 2009 18:07:24 +, Matthew Toseland wrote:
 fproxy can still be probed for, just not individual sites... We
 should also warn about it in the README...

You mean the executable/jar can still be probed for on the filesystem?
Maybe. But it can't be done via the network interface, if that iptables
rule is in place--the port would appear as dead as any other unused
port, as far as anyone except freenetuid would know.
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Freenet 0.7 build 1203

2009-01-24 Thread Matthew Toseland
On Saturday 24 January 2009 18:18, Dennis Nezic wrote:
 On Sat, 24 Jan 2009 18:07:24 +, Matthew Toseland wrote:
  fproxy can still be probed for, just not individual sites... We
  should also warn about it in the README...
 
 You mean the executable/jar can still be probed for on the filesystem?
 Maybe. But it can't be done via the network interface, if that iptables
 rule is in place--the port would appear as dead as any other unused
 port, as far as anyone except freenetuid would know.

I mean javascript port scanning. But yes you can do it with iptables rules.


pgpjukOL2qI3o.pgp
Description: PGP signature
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

[freenet-support] Freenet 0.7 build 1203

2009-01-23 Thread Ancoron Luciferis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Matthew Toseland wrote:
> On Thursday 22 January 2009 22:30, Ancoron Luciferis wrote:
>> Matthew Toseland wrote:
>>> Freenet 0.7 build 1203 is now available. Please upgrade.
>>>
>>> The main change in 1203 is that history cloaking is removed. It is very 
> messy
>>> code-wise and does not really solve the problem - for example, if a user
>>> posted the key for something they had inserted, and forgot to remove
>>> the ?secureid= added by history cloaking, a malicious website could then
>>> probe for that key with the secureid.
>>>
>>> The real solution to browser history stealing is simply to use a separate
>>> browser for Freenet than the one you use for the wider web. We now warn 
> users
>>> about this at the beginning of the first time wizard.
>> ^^ That is one more reason for the suggestion of a separate UI that I
>> made on freenet.uservoice.com. 
> 
> This is now largely accepted in the development team as a long-term goal. 
> saces is working on something like this based on wxWindows. However, a 
> dedicated browser/client (somewhere in between probably, e.g. there is no 
> point in converting all the config pages to tabbed dialogs) would likely be a 
> significant amount of work and require a significant amount of maintenance. 

^^ Well, and there I could help out.

> So it's not a priority for 0.8.0.
> 
>> And I feel that I have to restate what I 
>> said there to prefer XUL for such a client as for the following reasons:
>> 1.) widely used already (stable language, although not community driven)
>> 2.) easy to learn (it's just some XML paired with ECMA-Script - even a
>> lazy JEE/web developer like me was able to master that)
> 
> We do actually need some help with javascript, I don't know js...

^^ OK then, I'm ready to help on that for sure.

> 
>> 3.) common look and feel intregrated (most of the users already use some
>> other XUL based apps like Firefox, Thunderbird, aso.)
>> 4.) easy to extend (regarding to plugins, extensions, themes, aso.)
> 
> It will probably require some C++ (or java with mozswing) code, we would want 
> it to speak FCP for various reasons, and we'd want callbacks from incoming 
> FCP packets to some UI elements.

^^ That is why Mozilla created XPCOM. Its interfaces can be called
through privileged JavaScript which is the way all Mozilla apps work.
Today XPCOM components can be written in the following languages:
- - JavaScript
(https://developer.mozilla.org/en/How_to_Build_an_XPCOM_Component_in_Javascript)
- - C++ (https://developer.mozilla.org/en/XPCOM)
- - Java (https://developer.mozilla.org/en/JavaXPCOM)
- - Perl (https://developer.mozilla.org/en/PlXPCOM)
- - Python (https://developer.mozilla.org/en/PyXPCOM)
- - Ruby (https://developer.mozilla.org/en/RbXPCOM)

And that's why I really like it. Having the choice to use the most
simple for what you need.

> 
>> 5.) runs on nearly every platform
>>
>>> There are also some
>>> German translation updates by an anonymous contributor, and some work on 
> the
>>> README and the website.
>>>
>>> Apart from the above, Zero3 has started to commit his new windows 
> installer.
>>> saces has continued to work on his wxFCP project, which hopefully will 
> result
>>> in a custom browser for Freenet, which we may or may not use when it is
>>> finished, and robert has committed a spec file for generating RPMs for
>>> Freenet.
>> ^^ RPM? I would rather need DEB or S5R4 datastreams. JRPM over at
>> sourceforge is a straight forward library for creating/parsing RPMs
>> regardless of the platform it runs on. The software I'm developing on at
>> work makes extensive use of the JRPM library and it is used in many
>> production systems so it can be considered as stable. Also it supports
>> noarch packages. I was already about to start working on something
>> similar for Solaris PKG, as the very basics (CPIO streams) is the same
>> in both the RPM and S5R4 package system. Only the stuff around that
>> differs a lot but even on windows one can unpack a datastream PKG with
>> the standalone windows builds of GNU dd and cpio. So there's not much
>> magic. I don't like projects that deliver just one package format (and
>> RPM is really not my favorite one). When you are planning to release
>> freenet in package formats please do it for all or for none. But I would
>> suspect that creating a good MSI would be the hardest task anyway.
> 
> What are S5R4? We cannot support every package format, and we will have to 
> keep the java installer around because of this fact. But we would like to 
> support the major formats. Let us know if you are interested in helping in 
> any of the areas I have mentioned.

^^ S5R4 is for System 5 Release 4 packages which is the package system
used by Solaris and other Unixes. Here I can help out too as I am
familiar with the Solaris packaging system due to the fact that I work
in a company that makes money with software management.  :)

Regards,

AncoL
-BEGIN PGP 

[freenet-support] Freenet 0.7 build 1203

2009-01-23 Thread [Anon] Anon User
-BEGIN TYPE III ANONYMOUS MESSAGE-
Message-type: plaintext

In  Matthew Toseland  wrote:

>>> > > The real solution to browser history stealing is simply to use a 
>>> > > separate
>>> > > browser for Freenet than the one you use for the wider web. We now warn 
> users
>>> > > about this at the beginning of the first time wizard.
>> > 
>> > ^^ That is one more reason for the suggestion of a separate UI that I
>> > made on freenet.uservoice.com. 
> 
> This is now largely accepted in the development team as a long-term goal. 
> saces is working on something like this based on wxWindows. However, a 
> dedicated browser/client (somewhere in between probably, e.g. there is no 
> point in converting all the config pages to tabbed dialogs) would likely be a 
> significant amount of work and require a significant amount of maintenance. 
> So it's not a priority for 0.8.0.

I hope that as Freenet moves to this new UI, somewhere in the days 0.8+++, that
plain old browser support is not discontinued.  There's plenty of us who know 
how
to be secure with a browser and don't mind doing things like using a separate
profile for the purpose with tighter settings.

I think there's a lot of use who prefer to stay with that functionality rather
than a shiny new whiz-bang UI.


-END TYPE III ANONYMOUS MESSAGE-



[freenet-support] Freenet 0.7 build 1203

2009-01-23 Thread Matthew Toseland
On Thursday 22 January 2009 22:30, Ancoron Luciferis wrote:
> Matthew Toseland wrote:
> > Freenet 0.7 build 1203 is now available. Please upgrade.
> >
> > The main change in 1203 is that history cloaking is removed. It is very 
messy
> > code-wise and does not really solve the problem - for example, if a user
> > posted the key for something they had inserted, and forgot to remove
> > the ?secureid= added by history cloaking, a malicious website could then
> > probe for that key with the secureid.
> >
> > The real solution to browser history stealing is simply to use a separate
> > browser for Freenet than the one you use for the wider web. We now warn 
users
> > about this at the beginning of the first time wizard.
> 
> ^^ That is one more reason for the suggestion of a separate UI that I
> made on freenet.uservoice.com. 

This is now largely accepted in the development team as a long-term goal. 
saces is working on something like this based on wxWindows. However, a 
dedicated browser/client (somewhere in between probably, e.g. there is no 
point in converting all the config pages to tabbed dialogs) would likely be a 
significant amount of work and require a significant amount of maintenance. 
So it's not a priority for 0.8.0.

> And I feel that I have to restate what I 
> said there to prefer XUL for such a client as for the following reasons:
> 1.) widely used already (stable language, although not community driven)
> 2.) easy to learn (it's just some XML paired with ECMA-Script - even a
> lazy JEE/web developer like me was able to master that)

We do actually need some help with javascript, I don't know js...

> 3.) common look and feel intregrated (most of the users already use some
> other XUL based apps like Firefox, Thunderbird, aso.)
> 4.) easy to extend (regarding to plugins, extensions, themes, aso.)

It will probably require some C++ (or java with mozswing) code, we would want 
it to speak FCP for various reasons, and we'd want callbacks from incoming 
FCP packets to some UI elements.

> 5.) runs on nearly every platform
> 
> > There are also some
> > German translation updates by an anonymous contributor, and some work on 
the
> > README and the website.
> >
> > Apart from the above, Zero3 has started to commit his new windows 
installer.
> > saces has continued to work on his wxFCP project, which hopefully will 
result
> > in a custom browser for Freenet, which we may or may not use when it is
> > finished, and robert has committed a spec file for generating RPMs for
> > Freenet.
> 
> ^^ RPM? I would rather need DEB or S5R4 datastreams. JRPM over at
> sourceforge is a straight forward library for creating/parsing RPMs
> regardless of the platform it runs on. The software I'm developing on at
> work makes extensive use of the JRPM library and it is used in many
> production systems so it can be considered as stable. Also it supports
> noarch packages. I was already about to start working on something
> similar for Solaris PKG, as the very basics (CPIO streams) is the same
> in both the RPM and S5R4 package system. Only the stuff around that
> differs a lot but even on windows one can unpack a datastream PKG with
> the standalone windows builds of GNU dd and cpio. So there's not much
> magic. I don't like projects that deliver just one package format (and
> RPM is really not my favorite one). When you are planning to release
> freenet in package formats please do it for all or for none. But I would
> suspect that creating a good MSI would be the hardest task anyway.

What are S5R4? We cannot support every package format, and we will have to 
keep the java installer around because of this fact. But we would like to 
support the major formats. Let us know if you are interested in helping in 
any of the areas I have mentioned.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 



Re: [freenet-support] Freenet 0.7 build 1203

2009-01-23 Thread Ancoron Luciferis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Matthew Toseland wrote:
 On Thursday 22 January 2009 22:30, Ancoron Luciferis wrote:
 Matthew Toseland wrote:
 Freenet 0.7 build 1203 is now available. Please upgrade.

 The main change in 1203 is that history cloaking is removed. It is very 
 messy
 code-wise and does not really solve the problem - for example, if a user
 posted the key for something they had inserted, and forgot to remove
 the ?secureid= added by history cloaking, a malicious website could then
 probe for that key with the secureid.

 The real solution to browser history stealing is simply to use a separate
 browser for Freenet than the one you use for the wider web. We now warn 
 users
 about this at the beginning of the first time wizard.
 ^^ That is one more reason for the suggestion of a separate UI that I
 made on freenet.uservoice.com. 
 
 This is now largely accepted in the development team as a long-term goal. 
 saces is working on something like this based on wxWindows. However, a 
 dedicated browser/client (somewhere in between probably, e.g. there is no 
 point in converting all the config pages to tabbed dialogs) would likely be a 
 significant amount of work and require a significant amount of maintenance. 

^^ Well, and there I could help out.

 So it's not a priority for 0.8.0.
 
 And I feel that I have to restate what I 
 said there to prefer XUL for such a client as for the following reasons:
 1.) widely used already (stable language, although not community driven)
 2.) easy to learn (it's just some XML paired with ECMA-Script - even a
 lazy JEE/web developer like me was able to master that)
 
 We do actually need some help with javascript, I don't know js...

^^ OK then, I'm ready to help on that for sure.

 
 3.) common look and feel intregrated (most of the users already use some
 other XUL based apps like Firefox, Thunderbird, aso.)
 4.) easy to extend (regarding to plugins, extensions, themes, aso.)
 
 It will probably require some C++ (or java with mozswing) code, we would want 
 it to speak FCP for various reasons, and we'd want callbacks from incoming 
 FCP packets to some UI elements.

^^ That is why Mozilla created XPCOM. Its interfaces can be called
through privileged JavaScript which is the way all Mozilla apps work.
Today XPCOM components can be written in the following languages:
- - JavaScript
(https://developer.mozilla.org/en/How_to_Build_an_XPCOM_Component_in_Javascript)
- - C++ (https://developer.mozilla.org/en/XPCOM)
- - Java (https://developer.mozilla.org/en/JavaXPCOM)
- - Perl (https://developer.mozilla.org/en/PlXPCOM)
- - Python (https://developer.mozilla.org/en/PyXPCOM)
- - Ruby (https://developer.mozilla.org/en/RbXPCOM)

And that's why I really like it. Having the choice to use the most
simple for what you need.

 
 5.) runs on nearly every platform

 There are also some
 German translation updates by an anonymous contributor, and some work on 
 the
 README and the website.

 Apart from the above, Zero3 has started to commit his new windows 
 installer.
 saces has continued to work on his wxFCP project, which hopefully will 
 result
 in a custom browser for Freenet, which we may or may not use when it is
 finished, and robert has committed a spec file for generating RPMs for
 Freenet.
 ^^ RPM? I would rather need DEB or S5R4 datastreams. JRPM over at
 sourceforge is a straight forward library for creating/parsing RPMs
 regardless of the platform it runs on. The software I'm developing on at
 work makes extensive use of the JRPM library and it is used in many
 production systems so it can be considered as stable. Also it supports
 noarch packages. I was already about to start working on something
 similar for Solaris PKG, as the very basics (CPIO streams) is the same
 in both the RPM and S5R4 package system. Only the stuff around that
 differs a lot but even on windows one can unpack a datastream PKG with
 the standalone windows builds of GNU dd and cpio. So there's not much
 magic. I don't like projects that deliver just one package format (and
 RPM is really not my favorite one). When you are planning to release
 freenet in package formats please do it for all or for none. But I would
 suspect that creating a good MSI would be the hardest task anyway.
 
 What are S5R4? We cannot support every package format, and we will have to 
 keep the java installer around because of this fact. But we would like to 
 support the major formats. Let us know if you are interested in helping in 
 any of the areas I have mentioned.

^^ S5R4 is for System 5 Release 4 packages which is the package system
used by Solaris and other Unixes. Here I can help out too as I am
familiar with the Solaris packaging system due to the fact that I work
in a company that makes money with software management.  :)

Regards,

AncoL
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


[freenet-support] Freenet 0.7 build 1203

2009-01-22 Thread Ancoron Luciferis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland wrote:
> Freenet 0.7 build 1203 is now available. Please upgrade.
> 
> The main change in 1203 is that history cloaking is removed. It is very messy 
> code-wise and does not really solve the problem - for example, if a user 
> posted the key for something they had inserted, and forgot to remove 
> the ?secureid= added by history cloaking, a malicious website could then 
> probe for that key with the secureid.
> 
> The real solution to browser history stealing is simply to use a separate 
> browser for Freenet than the one you use for the wider web. We now warn users 
> about this at the beginning of the first time wizard. 

^^ That is one more reason for the suggestion of a separate UI that I
made on freenet.uservoice.com. And I feel that I have to restate what I
said there to prefer XUL for such a client as for the following reasons:
1.) widely used already (stable language, although not community driven)
2.) easy to learn (it's just some XML paired with ECMA-Script - even a
lazy JEE/web developer like me was able to master that)
3.) common look and feel intregrated (most of the users already use some
other XUL based apps like Firefox, Thunderbird, aso.)
4.) easy to extend (regarding to plugins, extensions, themes, aso.)
5.) runs on nearly every platform

> There are also some 
> German translation updates by an anonymous contributor, and some work on the 
> README and the website. 
> 
> Apart from the above, Zero3 has started to commit his new windows installer. 
> saces has continued to work on his wxFCP project, which hopefully will result 
> in a custom browser for Freenet, which we may or may not use when it is 
> finished, and robert has committed a spec file for generating RPMs for 
> Freenet.

^^ RPM? I would rather need DEB or S5R4 datastreams. JRPM over at
sourceforge is a straight forward library for creating/parsing RPMs
regardless of the platform it runs on. The software I'm developing on at
work makes extensive use of the JRPM library and it is used in many
production systems so it can be considered as stable. Also it supports
noarch packages. I was already about to start working on something
similar for Solaris PKG, as the very basics (CPIO streams) is the same
in both the RPM and S5R4 package system. Only the stuff around that
differs a lot but even on windows one can unpack a datastream PKG with
the standalone windows builds of GNU dd and cpio. So there's not much
magic. I don't like projects that deliver just one package format (and
RPM is really not my favorite one). When you are planning to release
freenet in package formats please do it for all or for none. But I would
suspect that creating a good MSI would be the hardest task anyway.

Greetz,

AncoL

> 
> 1202 was related to history cloaking (making it configurable), and 1201 fixed 
> a bug causing the activelinks enabled setting not to be read on startup.
> 
> If you find any bugs, please report them on the bug tracker:
> https://bugs.freenetproject.org/
> 
> Thanks.
> 
> 
> 
> 
> ___
> Support mailing list
> Support at freenetproject.org
> http://news.gmane.org/gmane.network.freenet.support
> Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
> Or mailto:support-request at freenetproject.org?subject=unsubscribe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl485QACgkQHwxOsqv2bG3R6wCeMSd/xhz33Lp4VltG1tx31mwQ
XWQAoMWo3uDplXNLHTsTuiV2mMfA5rDV
=kzG2
-END PGP SIGNATURE-



Re: [freenet-support] Freenet 0.7 build 1203

2009-01-22 Thread Ancoron Luciferis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland wrote:
 Freenet 0.7 build 1203 is now available. Please upgrade.
 
 The main change in 1203 is that history cloaking is removed. It is very messy 
 code-wise and does not really solve the problem - for example, if a user 
 posted the key for something they had inserted, and forgot to remove 
 the ?secureid= added by history cloaking, a malicious website could then 
 probe for that key with the secureid.
 
 The real solution to browser history stealing is simply to use a separate 
 browser for Freenet than the one you use for the wider web. We now warn users 
 about this at the beginning of the first time wizard. 

^^ That is one more reason for the suggestion of a separate UI that I
made on freenet.uservoice.com. And I feel that I have to restate what I
said there to prefer XUL for such a client as for the following reasons:
1.) widely used already (stable language, although not community driven)
2.) easy to learn (it's just some XML paired with ECMA-Script - even a
lazy JEE/web developer like me was able to master that)
3.) common look and feel intregrated (most of the users already use some
other XUL based apps like Firefox, Thunderbird, aso.)
4.) easy to extend (regarding to plugins, extensions, themes, aso.)
5.) runs on nearly every platform

 There are also some 
 German translation updates by an anonymous contributor, and some work on the 
 README and the website. 
 
 Apart from the above, Zero3 has started to commit his new windows installer. 
 saces has continued to work on his wxFCP project, which hopefully will result 
 in a custom browser for Freenet, which we may or may not use when it is 
 finished, and robert has committed a spec file for generating RPMs for 
 Freenet.

^^ RPM? I would rather need DEB or S5R4 datastreams. JRPM over at
sourceforge is a straight forward library for creating/parsing RPMs
regardless of the platform it runs on. The software I'm developing on at
work makes extensive use of the JRPM library and it is used in many
production systems so it can be considered as stable. Also it supports
noarch packages. I was already about to start working on something
similar for Solaris PKG, as the very basics (CPIO streams) is the same
in both the RPM and S5R4 package system. Only the stuff around that
differs a lot but even on windows one can unpack a datastream PKG with
the standalone windows builds of GNU dd and cpio. So there's not much
magic. I don't like projects that deliver just one package format (and
RPM is really not my favorite one). When you are planning to release
freenet in package formats please do it for all or for none. But I would
suspect that creating a good MSI would be the hardest task anyway.

Greetz,

AncoL

 
 1202 was related to history cloaking (making it configurable), and 1201 fixed 
 a bug causing the activelinks enabled setting not to be read on startup.
 
 If you find any bugs, please report them on the bug tracker:
 https://bugs.freenetproject.org/
 
 Thanks.
 
 
 
 
 ___
 Support mailing list
 Support@freenetproject.org
 http://news.gmane.org/gmane.network.freenet.support
 Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
 Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl485QACgkQHwxOsqv2bG3R6wCeMSd/xhz33Lp4VltG1tx31mwQ
XWQAoMWo3uDplXNLHTsTuiV2mMfA5rDV
=kzG2
-END PGP SIGNATURE-
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Freenet 0.7 build 1203

2009-01-22 Thread Matthew Toseland
On Thursday 22 January 2009 22:30, Ancoron Luciferis wrote:
 Matthew Toseland wrote:
  Freenet 0.7 build 1203 is now available. Please upgrade.
 
  The main change in 1203 is that history cloaking is removed. It is very 
messy
  code-wise and does not really solve the problem - for example, if a user
  posted the key for something they had inserted, and forgot to remove
  the ?secureid= added by history cloaking, a malicious website could then
  probe for that key with the secureid.
 
  The real solution to browser history stealing is simply to use a separate
  browser for Freenet than the one you use for the wider web. We now warn 
users
  about this at the beginning of the first time wizard.
 
 ^^ That is one more reason for the suggestion of a separate UI that I
 made on freenet.uservoice.com. 

This is now largely accepted in the development team as a long-term goal. 
saces is working on something like this based on wxWindows. However, a 
dedicated browser/client (somewhere in between probably, e.g. there is no 
point in converting all the config pages to tabbed dialogs) would likely be a 
significant amount of work and require a significant amount of maintenance. 
So it's not a priority for 0.8.0.

 And I feel that I have to restate what I 
 said there to prefer XUL for such a client as for the following reasons:
 1.) widely used already (stable language, although not community driven)
 2.) easy to learn (it's just some XML paired with ECMA-Script - even a
 lazy JEE/web developer like me was able to master that)

We do actually need some help with javascript, I don't know js...

 3.) common look and feel intregrated (most of the users already use some
 other XUL based apps like Firefox, Thunderbird, aso.)
 4.) easy to extend (regarding to plugins, extensions, themes, aso.)

It will probably require some C++ (or java with mozswing) code, we would want 
it to speak FCP for various reasons, and we'd want callbacks from incoming 
FCP packets to some UI elements.

 5.) runs on nearly every platform
 
  There are also some
  German translation updates by an anonymous contributor, and some work on 
the
  README and the website.
 
  Apart from the above, Zero3 has started to commit his new windows 
installer.
  saces has continued to work on his wxFCP project, which hopefully will 
result
  in a custom browser for Freenet, which we may or may not use when it is
  finished, and robert has committed a spec file for generating RPMs for
  Freenet.
 
 ^^ RPM? I would rather need DEB or S5R4 datastreams. JRPM over at
 sourceforge is a straight forward library for creating/parsing RPMs
 regardless of the platform it runs on. The software I'm developing on at
 work makes extensive use of the JRPM library and it is used in many
 production systems so it can be considered as stable. Also it supports
 noarch packages. I was already about to start working on something
 similar for Solaris PKG, as the very basics (CPIO streams) is the same
 in both the RPM and S5R4 package system. Only the stuff around that
 differs a lot but even on windows one can unpack a datastream PKG with
 the standalone windows builds of GNU dd and cpio. So there's not much
 magic. I don't like projects that deliver just one package format (and
 RPM is really not my favorite one). When you are planning to release
 freenet in package formats please do it for all or for none. But I would
 suspect that creating a good MSI would be the hardest task anyway.

What are S5R4? We cannot support every package format, and we will have to 
keep the java installer around because of this fact. But we would like to 
support the major formats. Let us know if you are interested in helping in 
any of the areas I have mentioned.


pgp9XMOt8wlO6.pgp
Description: PGP signature
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

[freenet-support] Freenet 0.7 build 1203

2009-01-21 Thread Matthew Toseland
Freenet 0.7 build 1203 is now available. Please upgrade.

The main change in 1203 is that history cloaking is removed. It is very messy 
code-wise and does not really solve the problem - for example, if a user 
posted the key for something they had inserted, and forgot to remove 
the ?secureid= added by history cloaking, a malicious website could then 
probe for that key with the secureid.

The real solution to browser history stealing is simply to use a separate 
browser for Freenet than the one you use for the wider web. We now warn users 
about this at the beginning of the first time wizard. There are also some 
German translation updates by an anonymous contributor, and some work on the 
README and the website. 

Apart from the above, Zero3 has started to commit his new windows installer. 
saces has continued to work on his wxFCP project, which hopefully will result 
in a custom browser for Freenet, which we may or may not use when it is 
finished, and robert has committed a spec file for generating RPMs for 
Freenet.

1202 was related to history cloaking (making it configurable), and 1201 fixed 
a bug causing the activelinks enabled setting not to be read on startup.

If you find any bugs, please report them on the bug tracker:
https://bugs.freenetproject.org/

Thanks.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 



[freenet-support] Freenet 0.7 build 1203

2009-01-21 Thread Matthew Toseland
Freenet 0.7 build 1203 is now available. Please upgrade.

The main change in 1203 is that history cloaking is removed. It is very messy 
code-wise and does not really solve the problem - for example, if a user 
posted the key for something they had inserted, and forgot to remove 
the ?secureid= added by history cloaking, a malicious website could then 
probe for that key with the secureid.

The real solution to browser history stealing is simply to use a separate 
browser for Freenet than the one you use for the wider web. We now warn users 
about this at the beginning of the first time wizard. There are also some 
German translation updates by an anonymous contributor, and some work on the 
README and the website. 

Apart from the above, Zero3 has started to commit his new windows installer. 
saces has continued to work on his wxFCP project, which hopefully will result 
in a custom browser for Freenet, which we may or may not use when it is 
finished, and robert has committed a spec file for generating RPMs for 
Freenet.

1202 was related to history cloaking (making it configurable), and 1201 fixed 
a bug causing the activelinks enabled setting not to be read on startup.

If you find any bugs, please report them on the bug tracker:
https://bugs.freenetproject.org/

Thanks.


pgp9zEPzw3Ymv.pgp
Description: PGP signature
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe