Re: [freenet-dev] Distributed Version Control Update #7: GSoC Midterm Edition
On 08/03/2013 07:29 AM, Matthew Toseland wrote: > Thanks for your clear and comprehensive summary! I look forward to > trying it one day. I'm glad you found it clear! It is also my hope that this project will serve as a basis for other DVCS to add WoT support. >> With a target repository set, either a "default" or "default-push" >> path, or other Infocalypse configuration, to publish changes: >> hg fn-push >> hg push >> > You didn't say how to configure this - this is set up automatically > when you clone? Yes. URIs are set in the Infocalypse configuration when using fn-create. When creating a repository with clone, Infocalypse is currently unable to reverse the default path USK request URI for the WoT identity's subspace into an insert URI. Instead of adding support for this I plan to set the USK insert URI as the default-push path. Paths that use WoT lookups work fine, and in the case of push URIs are much safer because they only query local identities. Mercurial paths are set in the [paths] section of the .hg/hgrc ini file. For more information please see the documentation. [0] Thanks, Steve [0] http://www.selenic.com/mercurial/hgrc.5.html#paths signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] [#PJO-202-36851]: Re: Distributed Version Control Update #7: GSoC Midterm Edition
Discussion of development issues, Thank you for contacting us. This is an automated response confirming the receipt of your ticket. One of our agents will get back to you as soon as possible. For your records, the details of the ticket are listed below. When replying, please make sure that the ticket ID is kept in the subject line to ensure that your replies are tracked appropriately. Ticket ID: PJO-202-36851 Subject: Re: [freenet-dev] Distributed Version Control Update #7: GSoC Midterm Edition Department: Piracy [English] Type: Issue Status: Open You can check the status of or reply to this ticket online at: [1]https://support.teamspeakusa.com/index.php?/Tickets/Ticket/View/PJO- 202-36851 Kind regards, TeamSpeak USA, Inc. TeamSpeak Piracy e-Mail: [2]piracy at teamspeakusa.com Visit: [3]http://www.TeamSpeak.com Knowledgebase: [4]http://support.TeamSpeakUSA.com Hours of operation for this department are Monday - Friday, 9AM to 5PM Pacific Time (UTC-8). We are committed to responding to your inquiry within 48 hours, and typically will reply within 24 hours, excluding weekends and holidays. References 1. https://support.teamspeakusa.com/index.php?/Tickets/Ticket/View/PJO-202-36851 2. mailto:piracy at teamspeakusa.com 3. http://www.TeamSpeak.com/ 4. http://support.TeamSpeakUSA.com/
[freenet-dev] [#ZAK-391-75304]: Re: Maven and JNA
Discussion of development issues, Thank you for contacting us. This is an automated response confirming the receipt of your ticket. One of our agents will get back to you as soon as possible. For your records, the details of the ticket are listed below. When replying, please make sure that the ticket ID is kept in the subject line to ensure that your replies are tracked appropriately. Ticket ID: ZAK-391-75304 Subject: Re: [freenet-dev] Maven and JNA Department: Piracy [English] Type: Issue Status: Open You can check the status of or reply to this ticket online at: [1]https://support.teamspeakusa.com/index.php?/Tickets/Ticket/View/ZAK- 391-75304 Kind regards, TeamSpeak USA, Inc. TeamSpeak Piracy e-Mail: [2]piracy at teamspeakusa.com Visit: [3]http://www.TeamSpeak.com Knowledgebase: [4]http://support.TeamSpeakUSA.com Hours of operation for this department are Monday - Friday, 9AM to 5PM Pacific Time (UTC-8). We are committed to responding to your inquiry within 48 hours, and typically will reply within 24 hours, excluding weekends and holidays. References 1. https://support.teamspeakusa.com/index.php?/Tickets/Ticket/View/ZAK-391-75304 2. mailto:piracy at teamspeakusa.com 3. http://www.TeamSpeak.com/ 4. http://support.TeamSpeakUSA.com/
Re: [freenet-dev] Merging zidel/next into Freemail v0.2 fred-staging/master
On Friday 02 Aug 2013 17:49:30 Martin Nyhus wrote:
> On 08/02/2013 03:47 PM, Matthew Toseland wrote:
> > On Thursday 01 Aug 2013 19:35:47 Martin Nyhus wrote:
> >> I need to go though this is more detail, but some initial
> >> thoughts:
> >
> > Any reason not to forward/CC this to devl?
>
> Nope. Your original email wasn't sent there so I simply didn't think
> about it. I'll send the stuff from your email that I didn't quote
> separately.
>
> >>
> >> On 08/01/2013 02:47 PM, Matthew Toseland wrote:
> >>> 7c9b4d08894f319d0e7022a02d35d96899261958 - not safe, surely? -
> >>> headers can be encoded, can't they? is that implemented in
> >>> Freemail? - this part only deals with body ... but elsewhere
> >>> there must be support for quoted-printable etc in headers. in
> >>> which case this is bogus. Do they use the same charset? It
> >>> would be OK to pass through if the charset is only used for the
> >>> body - but the charset for the headers MUST be known. (and we
> >>> should test this). - it looks like there is support for encoded
> >>> headers. but it seems to be completely separate from support
> >>> for encoded body? SECURITY: quoted-printable etc in headers:
> >>> MUST NOT fallback to raw content!
> >>
> >> That function is only used for displaying things on web pages, so
> >> it is safe assuming the body is 7bit clean (as it should be).
> >> Since we don't actually check the content before displaying or
> >> when receiving we should either:
> >
> > If it's only displayed on a web page, then surely we add it with
> > new HTMLNode("#", string)? If so, it's safe, period.
> >
> > Having said that, my main concern here is header filtering: From,
> > To, etc. Stuff that might be meaningful to clients and cause them
> > to do bad things too. We don't decode before filtering? Should we?
> > Will an encoded From always be rejected?
>
> With the exception of the spoofed From header check, we don't do *any*
> filtering of incoming messages. When clients connect via IMAP they get
> the raw content we store on disk, the IMAP server doesn't decode stuff
> for them. A future filter for incoming messages must of course decode
> messages and generally try to parse what the clients will actually parse.
Are there bugs filed for this?
>
> >
> > Okay, so it's just a bit generous in what it accepts in the for()
> > loop, and unclear. And over-complicated as a result. There can only
> > be space, tab or carriage return, and we only need to writeEncoded
> > if it's a carriage return? Also you should rename the buffer, or at
> > least document it, to reflect the fact that it's always
> > whitespace.
>
> I don't remember all the details, but e.g. you can't end a line with
> whitespace, and you need to be careful about \r\n since it suddenly
> has two meanings depending on the context etc. I'll read the RFC again
> and
> fix/clarify/document the code.
Ok. This doesn't block a release though.
> >>
> >> Not sure I follow here. AssertionError is in java.lang, same
> >> thing that is thrown on assert(false). I can't see where anything
> >> in tools/ uses TextProtocolTester?
> >
> > assert(false) is a no-op unless assertions are explicitly enabled
> > at run-time with -enableassertions. Which is true for junit but not
> > true for tools here? Oh, you don't actually use them in testing
> > currently? Ok then.
>
> Ok my attempt at explaining it was awful. I throw AssertionError in
> the cases where my assumptions fail, mostly because I didn't want to
> write a lot of error handling code. This has nothing to do with junit
> or the unit tests in general. tools/send_receive_message runs a
> testcase that sends an email via SMTP using Freemail account 1 then
> receives it via IMAP using Freemail account 2. In other words, it
> automates sending a real message over the real network for testing,
> using the stuff in tools/src/.
Ok. IMHO it should use -enableassertions though.
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] Distributed Version Control Update #7: GSoC Midterm Edition
Thanks for your clear and comprehensive summary! I look forward to trying it one day. > With a target repository set, either a "default" or "default-push" > path, or other Infocalypse configuration, to publish changes: > hg fn-push > hg push > You didn't say how to configure this - this is set up automatically when you clone? 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] Summary of recent opennet discussions
On Friday 02 Aug 2013 19:12:31 Peter Todd wrote: > On Thu, Jul 25, 2013 at 12:36:34PM +0100, Matthew Toseland wrote: > > > Basically the security model is now an attacker has to outspend the > > > defenders in terms of Bitcoins sacrificed. Not perfect, but it may be of > > > value, especially in conjunction with other protections. They do have > > > potential anonymity issues, but we're talking about opennet where the > > > attacker knows your IP address anyway. There's also a varient of > > > proof-of-sacrifice where you prove you attempted to create Bitcoins, a > > > proof that has no linkage to any other Bitcoin transaction. > > > > AFAICS this is a slightly more complex form of "pay to join", with the > > dubious advantage that nobody gets the money. In theory this might help > > people to not think we're scammers (although transient mode is more > > important to that end) ... but by the time you've explained it, you've lost > > them anyway, so I doubt it's worth the additional complexity. > > Well any decentralized attempt to limit sybil attacks and other attacks > via some kind of limited resource ultimately boils down to "pay to > join", the question is what are you paying and how likely are honest > users to already have what they need to pay? > > > It's likely that for the foreseeable future, any attempt to charge an entry > > fee will result in losing a lot of nodes... (Not existing nodes, but > > potential nodes). > > Social issues are a real concern - we have this same problem in Bitcoin > with SPV nodes, like a light-weight smartphone wallet, that aren't > contributing back to the network but are consuming resources. How do you > distinguish between a botnet pretending to be tens of thousands of smart > phones and tens of thousands of real ones? People are allergic to any > kind of fee... > > Another option you might want to consider is proof-of-work. In some ways > it's not as effective, because like I said before often the actual cost > to attackers is less, but the social dimensions may be more effective. > What are your thoughts there? The proof-of-work could easily be > something that is gradually phased out and replaced by > proof-of-useful-work as the opennet peer responds to more and more > requests, doing useful work. Proof of work meaning hashcash? This is always going to be vastly cheaper for a competent attacker than for a user with low end hardware. 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] [#ZAK-391-75304]: Re: Maven and JNA
On Saturday 03 Aug 2013 09:41:02 TeamSpeak Piracy wrote: >Discussion of development issues, >Thank you for contacting us. This is an automated response confirming >the receipt of your ticket. One of our agents will get back to you as >soon as possible. For your records, the details of the ticket are >listed below. When replying, please make sure that the ticket ID is >kept in the subject line to ensure that your replies are tracked >appropriately. > Ticket ID: ZAK-391-75304 > Subject: Re: [freenet-dev] Maven and JNA > Department: Piracy [English] > Type: Issue > Status: Open >You can check the status of or reply to this ticket online at: >[1]https://support.teamspeakusa.com/index.php?/Tickets/Ticket/View/ZAK- >391-75304 >Kind regards, >TeamSpeak USA, Inc. What the hell is this? Somebody has registered an account on TeamSpeak support under Piracy (English) ... using *our mailing list* as email address ... and filed a ticket the contents of which are an innocuous email that AFAICS has nothing to do with either TeamSpeak or piracy. I have posted to the same effect on the ticket. 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] Maven and JNA
Matthew Toseland schrieb: > We should include JNA so we can use the patch to reduce Freenet's disk I/O > priority > on Windows. We can include this via auto-update as a separate jar. However, the official > jar is apparently built via Maven. We could include the official jar on the theory that > while Maven doesn't really meet our security requirements (there is still no download/compile > time verification of anything?), it's not only our problem if it's compromised. Or we could > try to figure out how to build it without Maven. Just a hint, if you still want to build it without maven: You can use maven once to create a build.xml for ant, which (maybe after some tweaks) you can use to build your target package. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
