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.
>
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 sin
On Tue, Feb 3, 2009 at 9:54 PM, erik quanstrom 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 block.
Is it
> 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 a
> 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 ro
> but as i said, i'm naive when it comes to crypto; maybe
> there's no way of doing this with any decent degree
> of security or usefulness.
Encryption is always a two-way path: for every bit of piece of mind
encryption provides, there is a corresponding fear of losing access.
Also, encryption ten
> 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 hav
> 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 mo
> 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
2009/2/3 erik quanstrom :
>> 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
> 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 wan
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 ro
> 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 stil
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 enumer
> >> 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
> 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.
>> 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 vent
> > 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 the way data is managed.
>
> I'm not sure how you'd fix
> 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 the way data is managed.
I'm not sure how you'd fix this. What
> 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
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
> 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,
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
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
wrote:
> Ground Control to Major Bruce:
> I have the Acer Aspire One within reach.
>
Ground Control to Major Bruce:
I have the Acer Aspire One within reach.
Do you have any specific plans?
check ignitions,
ak
sauces ain't gone anywhere. my kitchen is still full of them. fluffy
just had soy and honey on his pasta and pate. and i can 9fs sources at
the same time.
just my 3 euros worth.
brucee
On Fri, Jan 30, 2009 at 4:18 PM, wrote:
>> Some level of smartness in how block traversal is made needs to
>>
> 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.
> i don't see how
> to make sense of venti-level syncing unless it is so basic that
> you dump all the blocks from one venti into another. in which
> case, no special tools are needed.
Granted, but then security becomes an issue. Perhaps not regarding
replica, but in the universal context.
++L
> 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
> 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
> 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 v
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 diff
On Thu, 2009-01-29 at 14:33 -0800, Russ Cox wrote:
> On Thu, Jan 29, 2009 at 1:09 PM, Roman V. Shaposhnik 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 merge without
On Thu, Jan 29, 2009 at 1:09 PM, Roman V. Shaposhnik 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 I hav
> 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
is that "inode number" has now become a "score" and gotten
m
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 m
> > all the files i checked were marked deleted in the log.
> > i think the problem was during database generation,
> > there was no connection to venti. my patch should
> > address that. i found it necessary when doing the
> > history transfer. bad wireless connection.
> >
> > maybe there's als
On Thu, Jan 29, 2009 at 9:30 AM, erik quanstrom wrote:
>> 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
What if the replica/pull script defaulted to start with archiving to venti and
print simple instruction how to restore in case of epic failure?
On the other hand, the -n flag works for me.
/G.
__
Går det långsamt? Skaffa dig en snab
> 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 wa
Replica and cvs/git/mercurial/darcs/whatever solve
similar but different problems.
Onr fundamental difference is that the latter set is
intended to keep trees exactly in sync, whereas
the design of replica expects you to want some files
to contain local changes that persist and are not
synced back
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 u
On Thu, 2009-01-29 at 08:15 -0800, ron minnich wrote:
> On Thu, Jan 29, 2009 at 4:12 AM, Uriel 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 br
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 change
On Thu, Jan 29, 2009 at 4:12 AM, Uriel 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. Have you tried it
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 r
> 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
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 w
> - 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 origi
> 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 ha
before getting too excited replacing one thing by another,
it's always worth discovering what actually did go wrong,
just in case the other thing would (for instance) have done much
the same thing in the circumstances, or perhaps has
different drawbacks. perhaps the problem is in the
script that u
On Wed, Jan 28, 2009 at 3:06 AM, Uriel 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 of replica,
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 w
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 la
hi patrick,
someone else can give a better answer for sure but let me give give a try
here. (sorry if you know this already or if i have misunderstood your
question).
would reverting to an older fossil snapshot work for you?
if so, you could do this (i have just outlined):
- boot via cdrom
- fi
> 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
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
> >
On Fri, Jan 23, 2009 at 3:54 PM, 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 times.
> Maybe so
> > 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
> 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
had
> 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
the problem is on your end. sounds like
either a dns problem or port blocking.
- erik
I usually try to avoid the "what happened to sources" email,
but what happened to sources? All I've been getting from
pull attempts for the past several days is
srv: dial tcp!sources.cs.bell-labs.com!9fs: connection refused
bind: /n/sources/plan9: '/n/sources/plan9' does not exist
servermount: bin
62 matches
Mail list logo
