n/listinfo/freenet-dev
--
Dev Random
Fingerprint: 3ABC FCEF 1BCE 4528 E4FD 15EB 173A 76D2 6959 DAF1
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/c87b3cc5/attachment.pgp>
> http://mirror.squidly.org/snapshots/
Good work!
___
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
print: 3ABC FCEF 1BCE 4528 E4FD 15EB 173A 76D2 6959 DAF1
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/
Simple SVK based subspaces, as in the key is hash(public_key + document_name)
so people can have many documents with guessable document_name (or enumerated)
protected by one public key, are already in the standard SVK code.
On Mon, 07 Aug 2000, Ian Clarke wrote:
> > After much thought and conside
Scott changed the clients over from KHKs to KSKs. Since which is being used is
transparent to the user, that is not an issue with the usage. There are some
issues we the sorry state of the client code that's making things like
restarting on bad data difficult.
There is no direct SVK or CHK suppor
Not sure if this is a taboo subject (it shouldn't be) but I'd love to see a
Macintosh version of the Freenet client. OS 8/9 development would be pretty
pointless, but OSX Cocoa development would be very good and very welcome.
Being a fledgling programmer I speak with little knowledge of the
possibi
> What's the most useful thing to mirror? Nightly snapshots? Just the
> current source tree?
I think that a monthly mirror of the entire web site and a weekly source
snapshot should be sufficient.
___
Freenet-dev mailing list
Freenet-dev at lists.s
bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/fed1cca5/attachment.pgp>
The Street finds its own uses for technology.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/625837c7/attachment.pgp>
> the server code to hold on to DNS names instead of converting to IPs, but
> it shouldn't be too difficult.
That's a single line somewhere. I'll go look for it, since I put it there
for some reason that was quite reasonable at the time.
___
Freenet-
ad of converting to IPs, but
it shouldn't be too difficult.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/6cb82cbb/attachment.pgp>
dling a Reply to wait for a QueryRestarted on data
restarts.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/99a7a7ff/attachment.pgp>
> Why not use simple DNS? If freenet did use DNS in stead of IP numbers,
> the people who'd like to run a node on a dynamic IP could get a
> hostname/domain with dhs.org and probably elsewhere as well.
Yep.
> Or is DNS a security risk? I cannot think of any way how, but that
> means nothing.
Th
: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/3ca7462e/attachment.pgp>
ugh. Other thoughts?
Scott
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/d9053471/attachment.pgp>
> Perhaps fixing up the clients would be a good small job for me to start
> with?
The clients certainly need a lot of work. There is some wizardry
involved (just a little). But if you think you're up to it, you're more
than welcome to try your hand at improving the clients. Perhaps we could
IRC t
attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/1f48b151/attachment.pgp>
> Honestly, looking at Old* vs new *, the only real differences I could see
> was that all the existing code was moved around. I think a real rewrite
> might be in order.
Before it was a single main function. Now it is broken down into
overridable functions so that it can be subclassed by othe
> can we add spam/advertising crap insertion/user harassment to that ? Some
> guy on flatplanet.net has been using gnutella to spam his message
> across...every search from that node (or set of nodes he's using) is being
> returned with fake ips and positive search results with the spam attached
>
> also, what about someone hosting a mirror of the site? ie. perhaps a
> mirror once a week > day instead of whatever the CVS refresh is now?
Some mirrors would be cool. Of course, eventually we should just be able
to put the site in Freenet and it will get mirrored, but for right now a
couple
On Mon, 07 Aug 2000, hal at finney.org wrote:
<>
> There is a field for the total message length in the headers, of course.
> I assume it includes the hashes and check bytes? So you can tell when you
> have reached the final block by keeping track of how many bytes total you
> have left. If ther
On Mon, 07 Aug 2000, Michael ROGERS wrote:
> >KSKs are equal to KHKs. They just arent forgable. We most certainly have
> >guessable keys.
>
> If KSK are guessable, they are forgable. See my post to freenet-tech for
> details.
KSK's are not secure, but we think/hope they are obscured enough to
he difference between genius and stupidity is that genius has its limits.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/8797a061/attachment.pgp>
On Mon, 07 Aug 2000, Ian Clarke wrote:
<>
> Ok, how is this for a solution to this exploit: Rather than using the
> position in the datastore found by the method I describe as the insert
> point for the data, it is used as a lower-bound for the insert point,
> ie. the data is inserted at a random
Howdy!
I have a quick question, does anyone have a full backup of the
freenet.sourceforge.net site? if not, should that be put on the option as
a distributed backup?, as many people in as many countries as possible who
are developers/trusted?
also, what about someone hosting a mirror of the si
ment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/eabe2f82/attachment.pgp>
Oskar Sandberg wrote:
> Simple SVK based subspaces, as in the key is hash(public_key + document_name)
> so people can have many documents with guessable document_name (or enumerated)
> protected by one public key, are already in the standard SVK code.
I propose that as soon as 0.3 is released - w
Oskar Sandberg wrote:
>
> Simple SVK based subspaces, as in the key is hash(public_key + document_name)
> so people can have many documents with guessable document_name (or enumerated)
> protected by one public key, are already in the standard SVK code.
Oops, didn't spot that - you guys have be
> After much thought and consideration, I find myself coming around to
> Oskar's point of view on subspaces, in that an entire language (albeit
> without control-flow) may be overkill, and that a simpler SVK-based
> mechanism might be better.
>
> As soon as I get time I will look at implementing
> > Ok, how is this for a solution to this exploit: Rather than using the
> > position in the datastore found by the method I describe as the insert
> > point for the data, it is used as a lower-bound for the insert point,
> > ie. the data is inserted at a random position above this point.
>
> T
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/85923849/attachment.html>
I note in the client changelog that modifications appear to have been
made to make them up-to-date with recent key improvements, but can't see
this reflected in the usage help message. Are the Java clients now
fully ok with the new key stuff?
Ian.
___
After much thought and consideration, I find myself coming around to
Oskar's point of view on subspaces, in that an entire language (albeit
without control-flow) may be overkill, and that a simpler SVK-based
mechanism might be better.
As soon as I get time I will look at implementing this.
Ian.
On Fri, 04 Aug 2000, Scott G. Miller wrote:
<>
> Ah, I believe your right. The solution is to not use a BlockingQueue, but
> rather a BlockingStack. That way reclaimed threads get used in preference
> over new threads.
Speaking of this, I keep forgeting to ask, should I go to the ThreadPool thin
> I propose that as soon as 0.3 is released - we start to insert daily
> snapshots protected by SVK subspaces, I have a antsy feeling that
> Sourceforge will be the first target of any legal challenge to Freenet.
Very good idea.
___
Freenet-dev maili
> What I'd like to do is have a 0.3 release with full server support of all
> the new keytypes, then release a 0.3.1 with an updated client not too much
> later.
Good idea.
___
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://list
> Scott changed the clients over from KHKs to KSKs. Since which is being used is
> transparent to the user, that is not an issue with the usage. There are some
> issues we the sorry state of the client code that's making things like
> restarting on bad data difficult.
If you have some recommendat
s
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/dec97767/attachment.pgp>
data. Note that document
encryption should proceed as outlined in the document-encryption
(end-to-end) specs.
Ask oskar about the CHK hashes.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 byte
Hello, everyone.
I'd like to join your development team, if I might. I have very strong
Java and cryptography experience, and I am very keen on this project. My
experience includes the working on the JDK for IBM back in 1997, and an
Internet Banking application for a bank.
I'm also full of idea
On Tue, 8 Aug 2000, Stephen Blackheath wrote:
> There's a cryptanalysis of the Rijndael algorithm at
> http://www.counterpane.com/rijndael.html. I haven't got into detail, but
> it looks a little worrying.
>
> This brings me to... The issue of what ciphers to use. Has anyone given
> thought to
Oskar writes:
> The DataLength includes all the control characters and alike. This is for
> abstractions sake, DataLength is used by the connection layer to know how much
> to read of the socket, it shouldn't have to deal with control bytes and alike
> (except for being able to interrupted) when th
On Sun, 6 Aug 2000 06:36:08 -0700,
freenet-dev-admin at lists.sourceforge.net wrote:
>> Sorry if this has been already proposed but i was thinking that a node
>> should probably keep longer the files it is more likely to be requested
>> for (ie the closest to its key) & delete first files that are
On Sun, 6 Aug 2000 06:36:08 -0700,
freenet-dev-admin at lists.sourceforge.net wrote:
>
>But this happens naturally since the file is moved to the top of the stack
>every time it is requested. I don't think there is any reason to artificially
>inflate it.
>
>On Sun, 06 Aug 2000, Muzzle wrote:
>> So
> > c) You'd need to make sure searchData() does the same thing (if you want it
> > too).
> H, I assumed that searchData() would use the put() method, but I will
> check this.
Yep, its cool - searchData() uses the put() method, so the mod affects
it already.
Ian.
___
> > a) So if I take a key value and insert exactly one byte of data for it, that
> > data will never expire? What if I flood Freenet with thousands of one byte
> > inserts? Will they be blocking datastores (which are limited by number of
> > entries as well) and never be cleared?
> This may be an
>KSKs are equal to KHKs. They just arent forgable. We most certainly have
>guessable keys.
If KSK are guessable, they are forgable. See my post to freenet-tech for
details.
Michael
___
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
h
Visit http://whiterose.sourceforge.net/, it is a C++ version of Freenet
being developed by Adam Langley .
Ian.
Paul Bartlett wrote:
>
> Hi Folks,
> >
> > I know that all the main development is happening with Java, but
> > I'm not much of a Java guru. I was thinking about implementing
> > a C++
ttachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/e3ed96a9/attachment.pgp>
eenetproject.org/pipermail/devl/attachments/2807/83f74d1f/attachment.pgp>
on/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/8570c04e/attachment.pgp>
he simpler option (no
negotiation) also turns out to be the best one.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/c791a2c5/attachment.pgp>
-
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/a559d729/attachment.pgp>
--
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/370de26a/attachment.pgp>
> If he really wants to code so bad I'm sure we can find something for him.
I agree.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2807/efb2a9f6/attachment.pgp>
Dev Random wrote:
>
> * HTML rewriting
>
> In addition to rewriting Directory documents as HTML, the Adapter is also
> able to rewrite any HTML that passes through it, replacing references
> to the freenet URL scheme with HTTP references to itself.
>
> For example, "freenet://.svk/docs/traffic.h
56 matches
Mail list logo
