On 06.04.2012 00:38, C. Michael Pilato wrote:
I've been also frustrated when considering the situation that occurs when a
user changes his/her master password, forcing a re-encryption of all cached
credentials using the new password.
You could do what whole-disk encryption systems do: only the
Branko Čibej wrote on Fri, Apr 06, 2012 at 08:06:32 +0200:
This makes me wonder if we couldn't perhaps keep the whole thing as an
in-memory-not-disk-backed SQLite database, then encrypt and dump the
whole SQLite memory snapshot to disk. The real trouble with that
approach is that debugging the
On 06.04.2012 09:51, Daniel Shahaf wrote:
Branko Čibej wrote on Fri, Apr 06, 2012 at 08:06:32 +0200:
This makes me wonder if we couldn't perhaps keep the whole thing as an
in-memory-not-disk-backed SQLite database, then encrypt and dump the
whole SQLite memory snapshot to disk. The real
On Apr 6, 2012 3:58 AM, Branko Čibej br...@apache.org wrote:
On 06.04.2012 09:51, Daniel Shahaf wrote:
Branko Čibej wrote on Fri, Apr 06, 2012 at 08:06:32 +0200:
This makes me wonder if we couldn't perhaps keep the whole thing as an
in-memory-not-disk-backed SQLite database, then encrypt
On Thu, Apr 5, 2012 at 9:48 PM, Greg Stein gst...@gmail.com wrote:
On Apr 5, 2012 2:43 PM, hwri...@apache.org wrote:
Author: hwright
Date: Thu Apr 5 18:43:20 2012
New Revision: 1310005
URL: http://svn.apache.org/viewvc?rev=1310005view=rev
Log:
On the ev2-export branch:
Use an Ev2-style
On Apr 6, 2012 8:56 AM, Hyrum K Wright hyrum.wri...@wandisco.com wrote:
On Thu, Apr 5, 2012 at 9:48 PM, Greg Stein gst...@gmail.com wrote:
On Apr 5, 2012 2:43 PM, hwri...@apache.org wrote:
Author: hwright
Date: Thu Apr 5 18:43:20 2012
New Revision: 1310005
URL:
On 04/05/2012 10:33 PM, Greg Stein wrote:
If not, any suggestions on where the master passphrase fetch/store
bits might best fit in?
A new callback. But you definitely need a DSO option so core svn does not
have GNOME/KDE dependencies. Instead, they load a small DSO that implements
the
On 04/06/2012 02:06 AM, Branko Čibej wrote:
On 06.04.2012 00:38, C. Michael Pilato wrote:
I've been also frustrated when considering the situation that occurs when a
user changes his/her master password, forcing a re-encryption of all cached
credentials using the new password.
You could do
On Fri, Apr 6, 2012 at 8:53 AM, Greg Stein gst...@gmail.com wrote:
On Apr 6, 2012 8:56 AM, Hyrum K Wright hyrum.wri...@wandisco.com wrote:
On Thu, Apr 5, 2012 at 9:48 PM, Greg Stein gst...@gmail.com wrote:
On Apr 5, 2012 2:43 PM, hwri...@apache.org wrote:
Author: hwright
Date: Thu
On 04/06/2012 04:22 AM, Greg Stein wrote:
Yeah, I switched the master passphrase param to an svn_string_t on the
probable outcome that we would immediately SHA1 the thing, and then use the
resulting hash as the nominal password. That would avoid having the
plaintext in memory (and yes, I
On 04/02/2012 07:52 PM, Greg Stein wrote:
On Mon, Apr 2, 2012 at 10:57, cmpil...@apache.org wrote:
Author: cmpilato
Date: Mon Apr 2 14:57:14 2012
New Revision: 1308372
URL: http://svn.apache.org/viewvc?rev=1308372view=rev
Log:
Some cleanups and minor tweaks to the crypto code.
*
On Apr 6, 2012 10:36 AM, C. Michael Pilato cmpil...@collab.net wrote:
On 04/06/2012 04:22 AM, Greg Stein wrote:
Yeah, I switched the master passphrase param to an svn_string_t on the
probable outcome that we would immediately SHA1 the thing, and then use
the
resulting hash as the nominal
On Apr 6, 2012 2:06 AM, Branko Čibej br...@apache.org wrote:
On 06.04.2012 00:38, C. Michael Pilato wrote:
I've been also frustrated when considering the situation that occurs
when a
user changes his/her master password, forcing a re-encryption of all
cached
credentials using the new
On Apr 6, 2012 10:45 AM, C. Michael Pilato cmpil...@collab.net wrote:
On 04/02/2012 07:52 PM, Greg Stein wrote:
...
To be honest, one of my intended updates is to move *all* of the
#ifdef stuff into crypto.c's functions. We've had problems where
functions only appeared within certain build
On 04/06/2012 10:47 AM, Greg Stein wrote:
Correct. Still useful, but even if memory is compromised, the SHA1 is
not reversible. The original MP cannot be recovered for other uses.
Just as a reminder, SHA-1 is not recommended for use in new applications
at this time
On 06.04.2012 16:13, C. Michael Pilato wrote:
On 04/06/2012 02:06 AM, Branko Čibej wrote:
On 06.04.2012 00:38, C. Michael Pilato wrote:
I've been also frustrated when considering the situation that occurs when a
user changes his/her master password, forcing a re-encryption of all cached
On 06.04.2012 16:55, Greg Stein wrote:
On Apr 6, 2012 2:06 AM, Branko Čibej br...@apache.org wrote:
On 06.04.2012 00:38, C. Michael Pilato wrote:
I've been also frustrated when considering the situation that occurs
when a
user changes his/her master password, forcing a re-encryption of all
On 04/06/2012 11:02 AM, Branko Čibej wrote:
*sigh* I hadn't considered stale, compromised data not yet purged or
overwritten. Does SQLite's VACUUM statement help with this problem?
http://sqlite.org/lang_vacuum.html
Vacuum will reorder the pages in the file to fill holes, but will then
On 04/06/2012 10:55 AM, Greg Stein wrote:
In other words, changing the master passphrase only requires decrypting
and re-encrypting one 256-bit encryption key, not the whole credentials
store.
PKBDF2 is in the current design to make dict attacks computationally
impossible. Assuming we keep
On Wed, Apr 4, 2012 at 1:28 PM, Ashod Nakashian
ashodnakash...@yahoo.com wrote:
I feel this is indeed what we're closing on, at least for an initial working
demo. But I'd like to hear more agreements before committing to this path. I
know some did show support for this approach, but it's hard
On 06.04.2012 17:07, C. Michael Pilato wrote:
On 04/06/2012 11:02 AM, Branko Čibej wrote:
*sigh* I hadn't considered stale, compromised data not yet purged or
overwritten. Does SQLite's VACUUM statement help with this problem?
http://sqlite.org/lang_vacuum.html
Vacuum will reorder the pages
*sigh*
I spoke in haste. It turns out my ruby-fu is so weak (and the code is
question is convoluted by the plethora of yield statements) that I
feel uncomfortable digging into this in any reasonable timeframe. I
*think* Daniel's patch would be useful, but I'm really in no position
to say.
In case folks haven't been following commits@, there's been a bit of
work on the ev2-export branch on implementing Ev2 drivers for commits.
While we're not quite ready for it yet, at some point we'll need to
start thinking about how to marshall Ev2 drives over the wire to
waiting servers. As
On Apr 6, 2012 2:05 PM, Hyrum K Wright hyrum.wri...@wandisco.com wrote:
In case folks haven't been following commits@, there's been a bit of
work on the ev2-export branch on implementing Ev2 drivers for commits.
While we're not quite ready for it yet, at some point we'll need to
start
On Fri, Apr 6, 2012 at 1:10 PM, Greg Stein gst...@gmail.com wrote:
On Apr 6, 2012 2:05 PM, Hyrum K Wright hyrum.wri...@wandisco.com wrote:
In case folks haven't been following commits@, there's been a bit of
work on the ev2-export branch on implementing Ev2 drivers for commits.
While we're
On Wed, Mar 28, 2012 at 2:30 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Philip Martin philip.mar...@wandisco.com writes:
There is another failure in the ruby testsuite:
http://ci.apache.org/builders/svn-x64-ubuntu-gcc/builds/4626
1) Failure:
On 04/06/2012 01:44 PM, Justin Erenkrantz wrote:
On Fri, Apr 6, 2012 at 8:09 AM, Greg Hudson ghud...@mit.edu wrote:
I also want to caution that PBKDF2 does not provide strong protection
against offline dictionary attacks. Most cryptographic methods provide
exponential protection--I do a
On Fri, Apr 6, 2012 at 11:02 AM, Hyrum K Wright
hyrum.wri...@wandisco.com wrote:
*sigh*
I spoke in haste. It turns out my ruby-fu is so weak (and the code is
question is convoluted by the plethora of yield statements) that I
feel uncomfortable digging into this in any reasonable timeframe.
On Fri, Apr 6, 2012 at 3:48 PM, hwri...@apache.org wrote:
Author: hwright
Date: Fri Apr 6 20:48:32 2012
New Revision: 1310581
URL: http://svn.apache.org/viewvc?rev=1310581view=rev
Log:
On the ev2-export branch:
Directly add any new directories, rather than through the path_info structs.
On Fri, Apr 6, 2012 at 11:32 AM, Joe Swatosh joe.swat...@gmail.com wrote:
On Wed, Mar 28, 2012 at 2:30 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Philip Martin philip.mar...@wandisco.com writes:
There is another failure in the ruby testsuite:
On Fri, Apr 6, 2012 at 16:53, Hyrum K Wright hyrum.wri...@wandisco.com wrote:
On Fri, Apr 6, 2012 at 3:48 PM, hwri...@apache.org wrote:
Author: hwright
Date: Fri Apr 6 20:48:32 2012
New Revision: 1310581
URL: http://svn.apache.org/viewvc?rev=1310581view=rev
Log:
On the ev2-export branch:
On Fri, Apr 6, 2012 at 4:31 PM, Greg Stein gst...@gmail.com wrote:
On Fri, Apr 6, 2012 at 16:53, Hyrum K Wright hyrum.wri...@wandisco.com
wrote:
On Fri, Apr 6, 2012 at 3:48 PM, hwri...@apache.org wrote:
Author: hwright
Date: Fri Apr 6 20:48:32 2012
New Revision: 1310581
URL:
On Sat, Apr 7, 2012 at 01:10, Greg Stein gst...@gmail.com wrote:
[...]
The plan is a new opaque structure that holds delete/modify/add
markers for relpaths. It doesn't need copy/move information, but just
what will be done at the relpaths.
Bikeshed: may be 'svn_editor_plan_t' -
On Fri, Apr 6, 2012 at 20:29, Ivan Zhakov i...@visualsvn.com wrote:
On Sat, Apr 7, 2012 at 01:10, Greg Stein gst...@gmail.com wrote:
[...]
The plan is a new opaque structure that holds delete/modify/add
markers for relpaths. It doesn't need copy/move information, but just
what will be done at
On Fri, Apr 6, 2012 at 17:36, Hyrum K Wright hyrum.wri...@wandisco.com wrote:
On Fri, Apr 6, 2012 at 4:31 PM, Greg Stein gst...@gmail.com wrote:
On Fri, Apr 6, 2012 at 16:53, Hyrum K Wright hyrum.wri...@wandisco.com
wrote:
...
Just so you know, I would have expected this section to crash Ev2
On Fri, Apr 6, 2012 at 8:17 PM, Greg Stein gst...@gmail.com wrote:
On Fri, Apr 6, 2012 at 17:36, Hyrum K Wright hyrum.wri...@wandisco.com
wrote:
On Fri, Apr 6, 2012 at 4:31 PM, Greg Stein gst...@gmail.com wrote:
On Fri, Apr 6, 2012 at 16:53, Hyrum K Wright hyrum.wri...@wandisco.com
wrote:
36 matches
Mail list logo
