ut a better long-term direction is to
design
accounting so that there are no remaining ambient authority issues, so that
CORS can
be enabled for all requests).
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev
ng list doesn't butcher Unicode; that's your font I think.
(I'm guessing it's not your mail client per se, unless there's a problem
specific to message display, because your reply is tagged correctly as
UTF-8 and preserved the bigender character in my sig.) You can probably
[1] way,
> i.e. no matter
> what host my app is launched from, I'd like it to use any tahoe server so
> configured for
> cross-origin requests.
Please see <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1215>, in particular
the
security considerations mentioned there.
--
Dav
gt; over there, then delete the version forked from warner and rename
> tahoe-lafs-redux to
> tahoe-lafs.
>
> Make sure NOT to fork tahoe-lafs-redux from tahoe-lafs, but instead create a
> new project
> and push to it directly ;)
I disagree, creating a new project would be un
If this is not a fast-forward then the push will fail, in which case
they rebase and push again.
> Can trac interact with a github pull request?
This workflow doesn't cause any problem for trac.
--
David-Sarah Hopwood ⚥
signature.asc
fs.org/trac/tahoe-lafs/ticket/614>, which is
planned to be fixed for v1.11.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
anyone else).
I added a note about this in NEWS.rst:
[https://github.com/tahoe-lafs/tahoe-lafs/commit/97a7cac7d3263e822d38f0d937b59dbb4dc366a9]
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
ta
laced
> without version number changes in these kinds of situations.
It may reduce the incidence for mutable files/directories, but we need
to make these fixes to the repair algorithm anyway.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
__
't know.
It's not strictly necessary for other repos to re-fork. The advantage
of doing so is that they'll get updates from trunk faster, because they
won't have to wait for Brian to pull from trunk to his repo. But not
re-forking does not create any impediment to int
; The response should have the same mime type. This follows normal REST design
> patterns.
It isn't clear that the separation of resources and representations in REST,
i.e. the fact that different representations don't have different URIs, is
actually a good idea. Certainly
Greg Troxel put
forward apply to such addresses, in general. It's quite plausible that a
Tahoe-LAFS grid could be made up entirely of nodes that are inter-routable
using FC00::/7 addresses.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
On 16/02/13 17:05, David-Sarah Hopwood wrote:
> On 16/02/13 12:49, Randall Mason wrote:
>> On Fri, Feb 15, 2013 at 4:28 PM, > <mailto:kpn...@pobox.com>> wrote:
>>
>> Is there really a need to restate the protocol next to the address? The
>> two addr
ed (in
src/allmydata/_auto_deps.py) to >= 12.1.0, as changing the dependency on
foolscap
to the version that supports IPv6.
(While setuptools/zetuptoolz/distribute would take note of the indirect
dependency
on >= 12.1.0 via foolscap anyway, this makes it clearer what version Tahoe
cal in tahoe requires a lot of complexity,
> clutters the lists of addresses, and results in clients trying to make
> connections that cannot succeed.
>
> So my advice is to at least for now, limit things to global addresses.
+1
--
David-Sarah Hopwood ⚥
signature.asc
Desc
eads to incremental
> complexity. Next one wants one distribution criteria for "good enough
> to place a file" and another for "good enough that we don't try to make
> it better".
The currently proposed algorithm is in
<https://tahoe-lafs.org/trac/tahoe-lafs/t
ot;.
That's covered by
<https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1784> and
<https://tahoe-lafs.org/trac/tahoe-lafs/ticket/614>.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
; this, I am a little unclear on if --repair just does a repair (regenerate
> missing shares),
> or also does a rebalance (move shares from node to node to improve
> redundancy).
Unfortunately, --repair does not rebalance. This is
<https://tahoe-lafs.org/trac/tahoe-lafs/ticket/699>, wh
1 not
> being recoverable. (Also, I think it should extend the lease on any
> non-recoverable shares.)
>
> Is there an existing bug about this? Or am I confused?
This is probably <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/755>.
Does the error look the same?
--
David-S
the
same format they appear in furls.
> After these side cases are thought out, tests, tests, and more tests!
Excellent.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.o
works. I thought the introducer node process had to be running
> in order to access the tahoe grid?
The introducer only has to be running in order to make connections between
client and server processes. Once those are connected, the introducer isn't
needed for as long as the client and s
e format of a single FURL is described at
<http://foolscap.lothar.com/docs/using-foolscap.html#auto7>;
that explains where the location hints go.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
ta
ints to the host running the new introducer.)
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
On 17/01/13 03:28, knuttila @dslextreme.com wrote:
> On Tue, Jan 15, 2013 at 11:42 PM, David-Sarah Hopwood
> <mailto:david-sa...@jacaranda.org>> wrote:
>
> Unfortunately the precompiled "egg" for that dependency is missing for
> 64-bit Python 2.7
>
> a blog who was following similar footsteps for a different application.
> Anyway, we installed
> the pywin32 pieces from sourceforge and all that went away.
It shouldn't be necessary to install pywin32. If you uninstall pywin32 (from
Add/Remove
Programs), what error message does it give exactly?
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
order to obtain a
new filecap that uses the new hash function. The integrity of a file
downloaded using the old filecap is still dependent on the old hash
function. In the case of encryption, however, reuploading the file
doesn't help against an attacker who has the old ciphertext.
--
David-Sar
would get a starter lease, right?
That depends whether we have periodic checking for shares that need
starter leases, or whether the scan for such shares has to be triggered
manually.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
al mode = default?
It's unclear from the other cases whether that would be faster or slower
than synchronous = NORMAL, journal mode = WAL.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
,
but if you are one, please use your non-work email for the Tahoe
trac :-)
In the unlikely event that this caught any legitimate accounts,
please accept my apologies, and just recreate the account with a
different pattern.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP di
store objects.
>"Does the leasedb need to track corrupted shares?"
>
>This is the same question as the previous one — a corrupted share
> is the same as a share with some of its objects missing.
If we do 3a) and a share has a corrupted header, then each time the shar
On 20/11/12 06:50, David-Sarah Hopwood wrote:
> On 19/11/12 17:34, Zooko Wilcox-O'Hearn wrote:
>> Thanks, David-Sarah, and I'll follow up on those particular patches
>> via github comments.
>>
>> But, this doesn't answer my question, which is: how can yo
n
even if it hasn't been edited at all. I don't remember this happening before
trac was last upgraded.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
iew comments?
>
> I guess one answer would be: all reviews get posted to github
> comment-on-the-patch, so then you can, when inspecting the patch, look
> for comments on it on github. Would that work?
That would work for me provided there is some way to extract all the
comments from
e of that in future. I usually file tickets for things that require
review, if I can't ask someone on IRC to review it immediately.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
On 08/11/12 19:18, David-Sarah Hopwood wrote:
> On 08/11/12 17:58, Andrew Miller wrote:
>> Warner gave a shared his screen and gave a demonstration of
>> merging/rebasing/remote-updating using git. Zooko and I need to find a
>> comparably snazzy revision-graph viewer for li
om the View menu. (The set of views is
remembered per-repo.)
The currently checked-out branch is at the top. It isn't always easy
to see where the other branches are in the graph, but you can do
File | List references (F2), and clicking on a reference will take
you to that position in
t of the reason why we use a gateway. If every command had to
establish a
connection to all servers, the per-command overhead would be *much* higher.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
that the Tahoe-LAFS gateway exports is the
> webapi.
That's not quite accurate; the FTP and SFTP interfaces are separate from
the web-API (but implemented by the same gateway node).
> ¹
> https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/network-and-relian
will support it though.
The relevant ticket would be
<https://tahoe-lafs.org/trac/tahoe-lafs/ticket/671>.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://ta
g "tahoe create-client" as described in
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/running.rst
?
> Everything seems right before that, so what is the problem?
By the way, we don't really recommend running Tahoe as root.
--
David-Sarah Hopwood ⚥
signature.as
ces import load_entry_point
> ImportError: No module named pkg_resources
>
> I do not know why...
If you upgrade to 1.9.2, then you can use "bin\tahoe debug flogtool" wherever
it says
"flogtool" in that doc.
(This is the easiest option on Windows.)
--
David-S
That's the minimal change from the existing code, though. I don't
think there's any overall simplification available unless we could remove
crawlers *entirely*, which I don't think we can do. We can always optimize
garbage collection later.
--
David-Sarah Hopwood ⚥
signature.asc
Des
On 18/10/12 20:48, Zooko Wilcox-O'Hearn wrote:
> On Fri, Oct 12, 2012 at 4:29 PM, David-Sarah Hopwood
> wrote:
>>
>>> The only difference between this and the current scheme is that the
>>> storage server will never do that on its own — it only does it when
&g
lf expire
leases.
Does this seem like it supports what you want?
If it does, then it doesn't require changes to the current leasedb
schema. There was previously some redundancy in the schema because an
lease that is past its expiration time was equivalent t
ad been updated when it hadn't? I think this is happening
whenever I comment on a ticket (possibly whenever anyone comments on a
ticket). It makes tahoe-lafs-trac-stream almost unusable.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
On 27/09/12 19:21, David-Sarah Hopwood wrote:
> On 27/09/12 17:27, Brad Rupp wrote:
>> I am getting a strange error while uploading files to Tahoe today. The
>> error is:
>>
>> "UploadUnhappinessError('shares could be placed on only 9 server(s) such
>&g
get install python-foolscap' on
Debian-based Linux
- run 'bin/tahoe @flogtool tail --catch-up
STORAGE_SERVER_BASEDIR/private/logport.furl'
See docs/logging.rst has more information about logging.
Is it Tahoe-LAFS 1.9.2 running on the client and all storage servers?
--
David-S
On 27/09/12 17:12, David-Sarah Hopwood wrote:
> On 27/09/12 16:27, Zooko Wilcox-O'Hearn wrote:
>> Topic: proof-of-storage/proof-of-retrievability
>>
>> CiC suggested a pass-through "Chess Grandmaster" style attack of
>> storage server which doesn'
ng those from k other shares. So it's really a proof
of knowledge rather than a proof of storage.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
On 25/09/12 07:33, David-Sarah Hopwood wrote:
> On 24/09/12 22:40, Tony Arcieri wrote:
>> On Mon, Sep 24, 2012 at 1:35 PM, David-Sarah Hopwood
>> > <mailto:david-sa...@jacaranda.org>> wrote:
>>
>> Integrity checking using a hash of the cipher
On 24/09/12 22:40, Tony Arcieri wrote:
> On Mon, Sep 24, 2012 at 1:35 PM, David-Sarah Hopwood
> <mailto:david-sa...@jacaranda.org>> wrote:
>
> Integrity checking using a hash of the ciphertext relies on the
> decryption being
> correct.
>
> I
ility that makes capabilities great
The current Tahoe design allows random keys. It doesn't require any extra field
in the
capability. There's just no UI to enable it at the moment.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
On 24/09/12 20:35, David-Sarah Hopwood wrote:
> On 23/09/12 20:11, Tony Arcieri wrote:
>> Why not use a hash (tree) of the ciphertext for this purpose? I suppose
>> encrypting the
>> hash of the plaintext accomplishes the same thing...
>
> In addition to CodesInC
dardized, it could potentially also be sent as an
HTTP header and checked by the web browser, giving better end-to-end integrity.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-l
On 20/09/12 01:26, Brian Warner wrote:
> On 9/19/12 4:09 PM, David-Sarah Hopwood wrote:
>> On 19/09/12 22:06, Zooko Wilcox-OHearn wrote:
>
>>> 2. human check (to discourage abuse), human chooses whether to add a
>>> comment to the revision (not to the pull requ
rcs workflow which would tell you if
there were unpulled changes on trunk, if you were paying attention.)
> Zooko would like to upgrade https://tahoe-lafs.org to Trac 1.0
> soonish. It includes a git network graph and builtin handling of git
> and multiple git bra
ttachment/ticket/127/restrict-referrer-leakage.txt
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
sufficient interest in having one for the North of England, I'll
find a hackerspace or somewhere similar in Manchester to have it in.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tah
On 11/09/12 20:54, David-Sarah Hopwood wrote:
> On 11/09/12 17:59, Zooko Wilcox-O'Hearn wrote:
>> There is still the question of how to handle hyperlinks into
>> https://tahoe-lafs.org that point at darcs patches and history.
>
> I think that the darcs history should be
as read-only, but
'darcs annotate' switched off to avoid performance problems on tahoe-lafs.org.
(We can remove obsolete darcs branches.)
> • topic: Will Cloud Backend, leasedb, and accounting go into Tahoe-LAFS v1.11?
We don't need to decide that yet, it depends whether they ar
On 05/09/12 04:47, Tony Arcieri wrote:
> On Tue, Sep 4, 2012 at 8:40 PM, David-Sarah Hopwood <mailto:david-sa...@jacaranda.org>> wrote:
>
> Well, not really. They can't fix security flaws without patching the
> browser code, which is sort-of technically p
. They can't fix security flaws without patching the
browser code, which is sort-of technically possible, but impractically
fragile. Fortunately, HTML5 sandbox addresses the same-origin issues at
least to the extent of being able to reliably create frames that have
their own unique origi
nvenient way to mention the public key we expect:
>
> package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
I missed this when you first posted it. I like it a lot.
The signature would be on the wheel binary package file?
--
David-Sarah Hopwood ⚥
signature.asc
Descr
ch
detail) is essentially a special case of Paxos with a gateway acting as both
Proposer
and (single) Learner, and the servers acting as Acceptors.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
On 02/08/12 19:39, markus reichelt wrote:
> * David-Sarah Hopwood wrote:
>
>> There's an argument for saying that this shouldn't just be a
>> warning; it should be an error, because running as root once may
>> already do things that need to be undone (e.g. crea
lready do things that need to be
undone (e.g. creating files owned by root, as in the case that motivated the
ticket).
If we made it an error then we could add an --allow-root option to suppress it;
is that necessary, or overcomplicated?
--
David-Sarah Hopwood ⚥
signature.asc
Description: Op
have 35 open tickets and have closed 36
tickets
related to setuptools:
https://tahoe-lafs.org/trac/tahoe-lafs/query?keywords=~setuptools&group=resolution&order=priority
A few of those are duplicates, some are only tangentially related to setuptools,
and one is a joke, but the number does fairly
ac/tahoe-lafs/ticket/445
"tcp hole-punching!"
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/169
"'rebalancing manager'"
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/543
"Automatically schedule repair process (and backups?)"
https://tahoe-lafs.or
tions; they don't
necessarily need to be in the right order for rebalancing to converge.)
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
On 12/07/12 05:29, David-Sarah Hopwood wrote:
> On 11/07/12 18:48, Zooko Wilcox-O'Hearn wrote:
>> Hm, according to this mailing list post --
>> http://mail.python.org/pipermail/python-list/2010-April/573606.html --
>> and this blog --
>> http://blog.victorjabur.com
press
(Visual C++ 2008 Express Edition with SP1).
You also need the Windows SDK for Windows 7 and .NET Framework 3.5 SP1:
http://www.microsoft.com/en-gb/download/details.aspx?id=3138
I haven't tested this because I don't have a copy of 64-bit Windows.
--
David-Sarah Hopwood ⚥
s
n which case we don't get any benefit from restoring the
backup, I think.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
9.2:
https://tahoe-lafs.org/trac/tahoe-lafs/browser/git/src/allmydata/storage/crawler.py?annotate=blame&branch=1.9.2#L193
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe
state file and deleting it will not cause
any problems.
I will improve the error message for this.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-l
ke
> baking "p2p style" into the introduction protocol.
Actually I think it would have been conceptually simpler for client
nodes never to be servers. Perhaps it's too late to change that, but
if we have to break compatibility in other ways then I think it would
not be an unreasona
c-cryptopp\x6
> 4dll.asm
Thanks for the report. I've built the necessary dependencies for 32-bit Windows,
but need someone to build Twisted and pycryptopp for 64-bit Windows. We'll try
to
have that done that by tomorrow.
--
David-Sarah Hopwood ⚥
signatu
o the
team of "hackers in the public interest" who make Tahoe-LAFS
possible.
David-Sarah Hopwood
on behalf of the Tahoe-LAFS team
July 3, 2012
Rainhill, Merseyside, UK
[1] https://tahoe-lafs.org/trac/tahoe-lafs/browser/NEWS.rst
[2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs
an I started
> backup on the
> [parent directory], which went through all the files really quick and also
> finished with
> success.
>
> But after all that, I can only find empty directories in the wb UI.
> My files seem to be there, but I can't find them.
What
ttp://git.repo.i2p.to/w/grid-updates.git/blob/master:/share/welcome.xhtml.patched19>),
and they look like something we want to have in upstream Tahoe.
Actually, they almost exactly implement
<https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1369>.
Can you attach your patches to tahoe.css and w
ith the darcs repo of trunk.
The 1.9.2 release is being done on a separate darcs branch (URL in zooko's
mail above, or tarball at
https://tahoe-lafs.org/source/tahoe-lafs/snapshots/allmydata-tahoe-1.9.2a1.tar.gz),
which does not have a git equivalent.
Testing trunk is useful because the 1.10 re
On 23/06/12 03:52, erp...@gmail.com wrote:
> Is the transition to git still happening?
Yes, after this release. (There will probably be a git branch equivalent
to this release as well.)
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signat
On 23/06/12 03:40, David-Sarah Hopwood wrote:
> On 22/06/12 16:51, Zooko Wilcox-O'Hearn wrote:
>> Also, it would be great to have some actual users try out 1.9.2 before
>> we finalize it.
>
> Definitely! Especially if you reported/experienced a bug against 1.9.1
> o
produced the following error messages. [...]
That should probably be equivalent to 'python setup.py --help'.
Filed as <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1779>.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
ed at
https://tahoe-lafs.org/source/tahoe-lafs/snapshots/allmydata-tahoe-1.9.2a1.tar.gz
,
except that zooko's tarballs are incorrectly tagged as 1.9.1a1, and the one I
posted is correctly tagged as 1.9.2a1.
--
David-Sarah Hopwood ⚥
signature.asc
Description: O
ary you got is incapable of
> handling HTTPS. In that case, you give up and complain to us and we'll
> post some tar.gz files for you to try out...
I posted a source tarball for 1.9.1a1 at
https://tahoe-lafs.org/source/tahoe-lafs/snapshots/allmydata-tahoe-1.9.2a1.tar.gz
(also .tar.bz2 an
e to find a bug that would be considered RC for
> Debian. If it pops up something in your mind, please tell me. :)
1.9.0/1 introduced several regressions in mutable file support (relative
to 1.8.3) that will be fixed in 1.9.2.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP
d consider Xanadu to have been wildly successful compared to the vast
majority
of research.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
hand, the error handling of 'tahoe backup' is a bit weak
and could be improved on all platforms.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
p * 2^128 / M operations, where p is the success probability and M is
the number of targets.
Increasing the IC to, say, 192 bits, makes low-probability and multi-target
attacks infeasible.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
S!&\\xb0\\xa1\\xeb\\x94\\x81F)\\xbb\\x89q\\x02\\x04\\x00\\x00\\x00\\x00\\x00\\x00\\x01P\\x00\\x00\\x00\\x00\\x00\\x00\\x01O',
> (('enc_privkey', 923), ('EOF', 2138), ('share_data', 755), ('signature', 399),
> ('block_hash_tree', 723), (&#x
On 28/05/12 23:42, Paul Grunwald wrote:
>
> Slowly making progress - Crypto is installed, only one test fails. 2.6 was
> the available version of Pycrypto
You shouldn't actually need to build pycrypto; only pycryptopp.
(I know the similar name is confusing.)
--
David-S
on-2-7-modules-on-windows-32-and-64-using-msvc-2008-express/>,
and use 'python setup.py bdist_egg' at the end to produce the egg distribution.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-de
e any expectations when the multiple introducer code will make
> it into the official stable?
Around version 1.11, I think.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
ac/wiki/Downloads>, but that probably won't help
without also having the pycryptopp egg).
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
e.html
The PDP-10 used words to measure memory size, i.e. its definition
of byte was not used as a unit.
Some systems define the size of a C 'char' to be greater than 8 bits,
but those are not bytes.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
__
t-tahoe-lafs/builders/clean/builds/55/steps/test-desert-island/logs/stdio
Unfortunately that test is unreliable (gives false passes) for any packages
that are installed on the desert island buildslave, as explained in ticket
#1346.
--
David-Sarah Hopwood ⚥
sign
via sshfs;
- merging the S3 backend support (and possibly other cloud service
support) developed by Least Authority Enterprises;
- extending the drop-upload feature to Windows;
- merging the patches for Tor and I2P into the main release.
--
David-Sarah Hop
ut it prefers a newer
> version from the network). Zooko, what do you think?
Yes, that's known behaviour, although I consider it a bug. Ticket #1346
is related but not the same problem.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
__
enerally we recommend to create a directory and an alias pointing to
it using 'tahoe create-alias', then upload files into that directory.
How could we improve the docs here?
> 9. I want a pony.
Filed as <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1736>.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
4.8
> minutes off the time.
Actually it means you have to reduce the time to 4.8 minutes on Brian's
laptop.
--
David-Sarah Hopwood ⚥
signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
ht
1 - 100 of 287 matches
Mail list logo
