On Tue, Feb 3, 2009 at 9:54 PM, erik quanstrom quans...@quanstro.net wrote:
Yes, but the content isn't guaranteed to be from a single user. In
fact, venti has no clue. Change that and it's not venti anymore.
exactly. but it's important to note that it's crypto hard to guess
somebody else's
On Tue, 2009-02-03 at 19:27 +0200, lu...@proxima.alt.za wrote:
But I do not recall the details and I think Roman is the one who
needs to recap this discussion and bring it to a conclusion.
Wow! This ended up being quite a thread ;-) I'll try to comment on
a couple of things first, in this
On Tue, 2009-02-03 at 17:30 +, Brian L. Stuart wrote:
information can't leak in principle, but root scores are dangerous, which
is why open-access venti servers are problematic - if such a score
*does* happen to leak, then unconditional access to all your data has
also leaked.
If I
ownership doesn't mean anything at the venti level. it really
is just a virtual disk drive with lba80 content addressing.
I think you mean lba160.
in the past i've pondered, in my crypto-naive way, if it
might be possible to make venti (or at least vac) somewhat
more secure by applying some kind of crypto to the
data structures containing scores.
to my mind, the biggest security vulnerability in venti
is the ability to unconditionally
to my mind, the biggest security vulnerability in venti
is the ability to unconditionally enumerate an entire file tree given
its root score. if the VtPointer data structures, or the
scores within them, were encrypted somehow, maybe
that vulnerability could be mitigated. scores would still
erik wrote:
i'm not sure i understand. either you have the key (score)
and you can decrypt the whole cyphertext (read the file tree
below), or you don't. assuming of course that scores are too
hard to guess. so the solution is: don't give out the root score.
my read on the utility of rog's
my read on the utility of rog's proposal is that you could then
pre-exchange the crypto key via secure channel (real live handoff or
whatnot) and then send root scores around freely over things like
email. unauthorized parties reading your email then don't get your
venti data.
if you want
2009/2/3 erik quanstrom quans...@quanstro.net:
to my mind, the biggest security vulnerability in venti
is the ability to unconditionally enumerate an entire file tree given
its root score. if the VtPointer data structures, or the
scores within them, were encrypted somehow, maybe
that
information can't leak in principle, but root scores are dangerous, which
is why open-access venti servers are problematic - if such a score
*does* happen to leak, then unconditional access to all your data has
also leaked.
what prevents using a non-root score in a similar fashion?
- erik
venti really doesn't
care what you store.
OK, enough agreement :-)
The issue is that to provide any level of privacy to venti is
impossible, it needs to be done at a higher layer. I think the
original request was for sources to be replicated at the venti block
level, something that could have
information can't leak in principle, but root scores are dangerous, which
is why open-access venti servers are problematic - if such a score
*does* happen to leak, then unconditional access to all your data has
also leaked.
If I understand correctly, this line of discussion
is primarily
i'm not sure i understand. either you have the key (score)
and you can decrypt the whole cyphertext (read the file tree
below), or you don't. assuming of course that scores are too
hard to guess. so the solution is: don't give out the root score.
fossil/last will find the most recent root
now getting rather jaded about the fact that my fresh fossil/venti
server has taken five days, twice, to dump -a little over 1GB of data
on two separate occasions, I'm not sure encryption is affordable.
i would imagine that cpu has nothing to do with it and encryption
would add no overhead at
On Fri, 2009-01-30 at 07:18 +0200, lu...@proxima.alt.za wrote:
Some level of smartness in how block traversal is made needs to
be there.
That involves partitioning, which defeats the fundamental mechanics of
venti.
I don't think it does. At least not in a way that is obvious to me.
The
I don't think it does. At least not in a way that is obvious to me.
The one and only fundamental limitation of the current interface
offered by venti is that I can give it a score to something that
doesn't belong to me and it gives me the information back. It is
the limitation of the API, not
On Mon, 2009-02-02 at 17:43 -0500, erik quanstrom wrote:
I don't think it does. At least not in a way that is obvious to me.
The one and only fundamental limitation of the current interface
offered by venti is that I can give it a score to something that
doesn't belong to me and it gives
Depends on how you look at it. From the drive's perspective -- you're
right. Nobody owns blocks. However, if a certain block happens
to be part of a filesystems that uses this particular drive then
the ownership can and will be tracked.
the problem comes in the fact that as far as venti is
I'm not sure how you'd fix this. What if only a portion of the block
belongs to me and the other happens to be the password file?
venti just stores whole blocks.
Yes, but the content isn't guaranteed to be from a single user. In
fact, venti has no clue. Change that and it's not venti
Ground Control to Major Bruce:
I have the Acer Aspire One within reach.
Do you have any specific plans?
check ignitions,
ak
Major Tom to Planet Earth.
I have no problems with tiny PCs. The eeePCs are still the best bet.
My Hellenic Lapdog is going to Brazil with me in a few hours.
brucee
On Sun, Feb 1, 2009 at 5:12 AM, Akshat Kumar
aku...@mail.nanosouffle.net wrote:
Ground Control to Major Bruce:
I have the Acer
Some level of smartness in how block traversal is made needs to
be there.
That involves partitioning, which defeats the fundamental mechanics of
venti. It then becomes preferable to run distinct venti services,
which is the only way in which different backing stores can be used at
this stage.
The issues with replica go beyond its tendency to wipe out complete
file systems.
It includes, among other things, the performance of a drunken slug,
and as you well point out, the skils of a schizophrenic monkey for
managing local changes.
All this has been solved by git and hg; and git and hg
i do not use replica to update my machine, but this is a reflection
of the fact that legitimate changes to files i've never changed can
remove functionality that i use, like il. i suspect that i'm a special
case in this regard and no amount of revision control fanciness
can save me.
I'm
On Thu Jan 29 07:13:32 EST 2009, urie...@gmail.com wrote:
It includes, among other things, the performance of a drunken slug,
i don't know how slow a drunken slug is. but before rushing
off to replace replica, it would be useful to see where the time
is going. you may find that your proposed
On Thu, Jan 29, 2009 at 4:12 AM, Uriel urie...@gmail.com wrote:
All this has been solved by git and hg; and git and hg would *never*
wipe out your local files simply because the backing store for the
repository you are pulling from happens to break,
Have you used git much? Sure, it's nice.
On Thu, 2009-01-29 at 13:12 +0100, Uriel wrote:
The issues with replica go beyond its tendency to wipe out complete
file systems.
It includes, among other things, the performance of a drunken slug,
and as you well point out, the skils of a schizophrenic monkey for
managing local changes.
On Thu, 2009-01-29 at 08:15 -0800, ron minnich wrote:
On Thu, Jan 29, 2009 at 4:12 AM, Uriel urie...@gmail.com wrote:
All this has been solved by git and hg; and git and hg would *never*
wipe out your local files simply because the backing store for the
repository you are pulling from
On Thu, 2009-01-29 at 08:37 -0500, erik quanstrom wrote:
and as you well point out, the skils of a schizophrenic monkey for
managing local changes.
well then, please show me how hg/git or whatever would save
me from the situation outlined. how would hg/git know that
i was really using
I can easily believe that the replica tools might
accidentally delete your whole file system (but only
the files that you hadn't changed) if sources all of
a sudden claims that the files are gone, like it did
a few days ago. It's trying to stay in sync with
sources, after all. This was a
On Thu, 2009-01-29 at 09:18 -0800, Russ Cox wrote:
Onr fundamental difference is that the latter set is
intended to keep trees exactly in sync,
trees tend to be highly overloaded, but if you refer
to the filesystem hierarchy as seem by open, then the
above statement, if applied to Git, is
On Thu, Jan 29, 2009 at 1:09 PM, Roman V. Shaposhnik r...@sun.com wrote:
trees tend to be highly overloaded, but if you refer
to the filesystem hierarchy as seem by open, then the
above statement, if applied to Git, is misleading.
What I mean is that if there is some file in the repository
and
On Thu, 2009-01-29 at 14:33 -0800, Russ Cox wrote:
On Thu, Jan 29, 2009 at 1:09 PM, Roman V. Shaposhnik r...@sun.com wrote:
I don't know how well Git handles this; I apologize for that.
Git doesn't get annoyed. In fact, with things like git stash you can
even test incremental changes to the
On Thu, 2009-01-29 at 16:42 -0500, erik quanstrom wrote:
That said, what would be your thoughts on developing the
tools (and interfaces perhaps) for fetching up venti
blocks between two systems in a secure and manageable way.
i think this harks back to ye olde dump. the main difference
There was a question on this list not long time ago whether
getting access to venti blocks of the sources would be possible.
The answer at the time was no. This is understandable since
the stock venti doesn't really offer any kind of security
mechanism for doing that.
However, the very fact
What do you mean by apply changes? Each venti has a set of
blocks corresponding to vac hierarchies. Each vac hierarchy
has a single parent. Retrieving the missing blocks reachable
from a hierarchy of interest to you is all that is needed.
you can put anything in venti. they don't need to be
after adding the needed features, what would the advantage
be over replica?
i'm fairly certain this discussion has diverged off
of replica and is now about just whether you could
build an interesting dvcs with venti as a low-level
building block, and if so, how.
russ
On Wed, Jan 28, 2009 at 3:06 AM, Uriel urie...@gmail.com wrote:
Mercurial and git solve all replica problems, and some more.
They are infinitely faster, more reliable, and more useful. And in
some ways they are even conceptually simpler (I never quite understood
some of the most subtle points
They [hg/mecurial] are infinitely faster, more reliable, and more useful. And
in
some ways they are even conceptually simpler (I never quite understood
some of the most subtle points of replica, like why it keeps saying it
needs to update files that were already updated if I happen to have
- find fossil's last score (using fossil/last command)
- format fossil partition with that score (flfmt command)
It may be necessary to go back one score, the morning surprise tends
to be after the archive snap.
I had to hack vacchain to return the score audit trail. Ask Russ
for the
On Fri, Jan 23, 2009 at 3:54 PM, lu...@proxima.alt.za wrote:
Hm, about as bad as when a couple of days ago I left replica/pull
running overnight and came back next morning to find that even /bin/ls
had disappeared.
You are not the only one to have woken up with such pleasant surprise
several
I did a pull yesterday and it has removed all my /386/ and it is now unable
to boot.
boot: /386/init: '/386/init' does not exist
panic: boot process died: unknown
panic: boot process died: unknown
dumpstack disabled
cpu0: exiting
Hints on how to restore are welcome
-Patrick
2009/1/23
But people keep telling me that replica's unreliability, painful
slowness, and general clunkyness, are all in my imagination, so what
do I know...
No, what we've told you, repeatedly, is that
whining about problems and fixing them are
two different things. Fixes are appreciated.
Russ
Hello,
Several years ago I abandoned replica and switched to my own tool
upadate,
but I hesitated to make it public because replica is so fundamental
tools
for Plan 9.
The major problem is(was?) replica doesn't properly arrange update
data-base
before it begins to retrieve files. The
Mercurial and git solve all replica problems, and some more.
They are infinitely faster, more reliable, and more useful. And in
some ways they are even conceptually simpler (I never quite understood
some of the most subtle points of replica, like why it keeps saying it
needs to update files that
srv: dial tcp!sources.cs.bell-labs.com!9fs: connection refused
bind: /n/sources/plan9: '/n/sources/plan9' does not exist
servermount: bind 545911: bind
Hm, about as bad as when a couple of days ago I left replica/pull
running overnight and came back next morning to find that even /bin/ls
46 matches
Mail list logo
