[freenet-support] From FMS: insertion error
On Sun, 25 Jan 2009 00:10:57 +0100, 3BUIb3S50i 3BUIb3S50i wrote: > herb at 5FeJUDg2ZdEqo-u4yoYWc1zF4tgPwOWlqcAJVGCoRv8 wrote: > > I have a big problem with recent releases (after 1194). > Uploads crash. See this screenshot: > CHK at > C8~jdMdN0Iz7TbKjmVmAmcuqIMFzkgQQjgpioFsaBnY,9GXBGEXt5v3UzVMEufgQTvvYtUBPwWWh > Vr5tOjYG9V8,AAIC--8/.jpg That screenshot isn't very helpful. It shows, uuuhh, a working upload? :) > Uploads stop before 100% and the files aren't uploaded correctly (O > KB if I try download them). 1195 introduced a change to the way CHK's are calculated (different padding). Maybe herb was trying to upload the same file across these irreconcilably differing freenet versions? Has he tried restarting the upload from scratch using the latest stable version?
[freenet-support] Freenet 0.7 build 1203
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: <https://emu.freenetproject.org/pipermail/support/attachments/20090124/cffdd3f1/attachment.pgp>
[freenet-support] Freenet 0.7 build 1203
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: <https://emu.freenetproject.org/pipermail/support/attachments/20090124/9390cdd5/attachment.pgp>
[freenet-support] Freenet 0.7 build 1203
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
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: <https://emu.freenetproject.org/pipermail/support/attachments/20090124/f5d926d9/attachment.pgp>
[freenet-support] Freenet 0.7 build 1203
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
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
-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
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
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
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
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
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
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] From FMS: insertion error
h...@5fejudg2zdeqo-u4yoywc1zf4tgpwowlqcajvgcorv8 wrote: I have a big problem with recent releases (after 1194). Uploads crash. See this screenshot: c...@c8~jdmdn0iz7tbkjmvmamcuqimfzkgqqjgpiofsabny,9GXBGEXt5v3UzVMEufgQTvvYtUBPwWWh Vr5tOjYG9V8,AAIC--8/.jpg Uploads stop before 100% and the files aren't uploaded correctly (O KB if I try download them). Please forward to developpers. I will try to reinstall freenet... -- 3buib3s...@gmail.com | dimonqm...@gmx.com ___ 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
