Sorry, responded to the wrong message.
That not only works, but also is a very clever idea. It reduces message
size and eliminates the possibility of gibberish entering the system.
It's also an excellent example of how ideas get better from being tossed
around.
Nice work.
On Thursday, April 3,
Yes, that works.
On Thursday, April 3, 2014, Vlad Khorsun
wrote:
> > Instead of get from info and pass "everything" (possible MBs?) in the
> > TPB, isn't possible to pass only the "base transaction number" of cloned
> > transaction, and them the engine instances dumps necessary information,
> >
I know of many very smart people who have tried to lick this problem
without success. Iy feels like there should be a solution, but avoiding an
ABA problem on release seems insurmountable.
An alternate solution that is close is thread specific sub-pools, which is
nice because a thread specific su
OK, I'll take the responsibility for the increment value for
generators/sequences. It seemed like a good idea at the time. But is it
actually useful for anything?
Based on 25 years of experience, I have to say that the ability to set back
a generator is a terrible idea that has led to more unmai
You might be interested to know that gpre, gbak, and dudley were initiated
on a PDP-11 based Pro-350 running Zenix (no, not Xenix) loaned by DEC. I
cut over to an Apollo DN-300 at the earliest opportunity to take advantage
of a 32 address space and gigantic 3MB of physical memory. The Apollo also
As Ann said, Interbase support 64 integers on the day it was born. Some
idiot at Borland decided that since PC compilers didn't support 64 bit, the
database didn't need to either. That said, I'll bet just about anything
that they never removed the 64 code (In the absence of runtime support for
64
It's internal to the event manager, but an "interest" in a named event
persists until the connection is closed.
In case I wasn't clear, the event notification call is one-shot -- one
registration, at most one notification.
There probably is a cancel event call, but it isn't anything you normally
I suggest you investigate garbage collecting intermediate
unreachable record versions, which would completely take the sting out of
long running transactions. It's not difficult for superserver, but would
be problematic for classic. But I don't think that in itself is a problem.
I have never lik
It's doable -- I implemented it in NuoDB, so consider that as an existence
proof.
On Wednesday, June 25, 2014, Nikolay Samofatov <
nikolay.samofa...@red-soft.biz> wrote:
> All,
>
> On 06/25/2014 09:41 AM, James Starkey wrote:
> > I suggest you investigate garba
You shouldn't have to care. The status vector is a well defined, self
describing data structure. A transmission protocol should pass it, not
interpret it. If you have to get involved in the semantics, you're either
doing something wrong (or somebody screwed up the architecture).
That said, the
other
hand, gmail is no damn good at inline comments, either.]
On Saturday, June 28, 2014, Dimitry Sibiryakov wrote:
> 28.06.2014 11:14, James Starkey wrote:
> > That said, the philosophy is that the frst code is primary -- something
> an application
> > programmer can make part o
e no scenarios when request-level
> snapshots would impose
> significant performance impact (long-running transactions would not
> inhibit GC anymore),
> and it would be possible to use them by default without breaking backwards
> compatibility.
>
>
> On 06/25/2014 02:27 P
There appears to be an impass: The desire to define an interface in C++
and the problems of cross compiler and cross language access to the API.
Here are some thoughts.
First, defining an API as an abstact object interface is the correct
approach. The original 30 year old interface took exactly
Something a very clever fellow might do would be to create and populate a
database capturing the interface then write an (extensible) program to
generate interface variants. It could, for example, produce the pure
virtual interface, the skeleton of the implementation classes, the flat
language ind
Could somebody send me a copy of the new API? We're off on our boat and
are both bandwidth and computationally challenged.
--
Jim Starkey
--
Want fast and easy access to all the code in your enterprise? Index and
search
Excuse me, sir, but the Ken Olson and Gordon Bell who built the second
largest computer company in the world were engineers. The jerk Palmer, who
wrecked it, was a "business type."
There's a great deal more to it, but big computer companies all became
dinosaurs. Wang, Prime, DG, DEC, Sun, Silico
The Vulcan strategy, not completed, was:
1. Maintain existing API.
2. Move SQL handling into core engine
3. Support JDBC has the interface for the future. New functionality would
be in JDBC first and probably only JDBC.
4. Extend protocol to support native JDBC.
There are efficiencies to be
There is no technical requirement to store sources for triggers and
procedures. It is done, presumably, for the convenience of application
developers. Some application developers, of which Carlos is just one, have
demonstrated that storing the sources is sometimes extremely inconvenient,
even det
Let's try another tack on this problem. What is the best possible way to
solve it if schedule were not a problem? And is this a special case of a
more general problem?
Here's an idea to get the creative juices working: Suppose the database
parameter block were extended with a composite containi
OK, my spelling has never been that goode.
But how about session specific field encryption?
Carlos?
On Sunday, August 31, 2014, Tom Coleman wrote:
>
>
> On Aug 31, 2014, at 9:39 AM, James Starkey wrote:
>
> This calls into question whether Firebird exists to serve the int
Excuse me, but the requirement is to make the source unreadable. Carlos
listed five ways this could be done. I came up with a sixth that is less
code, less instrusive, and more general than the others, and you say it is
unhelpfull. Why is this?
Decent engineering requires that you understand th
ou
encrypt the BLR version it won't work at all without the key.
On Monday, September 1, 2014, Dimitry Sibiryakov wrote:
> 01.09.2014 13:50, James Starkey wrote:
> > Selecting the source without the key would return hex or base64 gook.
> With the key, the
> > procedure source.
What possible user applications are going to be doing procedure and trigger
definitions that require the source be omitted? In all likelihood, the
option will be used exactly once in the DDL utility.
And what syntax are you talking about? There isn't any DPB syntax -- it's
a clumplet encoded str
September 4, 1984.
Why do you say it's dangerous? Mandatory indentation makes it clear.
Clear code separated into functional block is more legible if not cluttered
with superfluous punctuation.
On Tuesday, September 2, 2014, Dimitry Sibiryakov wrote:
>Hi, All.
>
>When was decided that
Something to keep in mind is that code is written once, modified a couple
of times, and read hundreds of times. Legitibilty is everything from a
maintenance perspective.
I've written, oh, close to a million lines of code. Two 4gls, four
relational database systems, a JVM, a search engine, a temp
The issue is often the cost of each step rather than the worst case number
of steps. In the final analysis implementations need to be measured over a
set of compilers rather comparison of the algorithms.
On Tuesday, September 23, 2014, Kjell Rilbe
wrote:
> Kjell Rilbe skrev:
>
> Vlad Khorsun s
Very impressive! The long running transaction problem has plagued the
system from the days of Groton Database Systems. A solution is long overdue.
On Friday, October 10, 2014, Nikolay Samofatov <
nikolay.samofa...@red-soft.biz> wrote:
> Hello, All!
>
> I have mostly completed my work for stat
What does TLS bring to the table if the authentication mechanism generates
a secure session key? Crypto libraries are a dime a dozen.
On Thursday, October 16, 2014, marius adrian popa wrote:
> Jim i wasn't talking about the auth part that is solved i was thinking
> about the encrypted data ch
Ann and I are settled at the hotel in Prague. Looking forward to seeing
everyone.
--
Jim Starkey
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice
The compound key scheme isn't quite right. Binary 0 bytes delimit keys,
binary 0s in a key are replaced with the sequence 1,0 and binary 1s in the
key are replaced with the sequence 1,1. So delimiter < 0 < 1 < everything
else. I wish I had invented it, but I only stole it.
On Monday, October 27
No, the intention was to support non-English clients, period.
Translation of both messages and national character sets is always best
done on the client. This shouldn't be a problem as a message file should
always be available, even if it's the default English version. If there
isn't a message f
The rational way to handle boolean is to store the value in a single byte
that is zero or one and use the boolean to string and string to boolean
conversion functions to translate zero or one to false and true,
respectively.
On Monday, November 17, 2014, Simonov Denis wrote:
> Why is half the Bo
On the list of vulnerabilities, this probably about 250. The probability
of a random collision is something like 2^79 instead of the design goal of
2^128, but the probabilty of a manufactured duplicate is still around 2^128.
SSL sucks right, left, and center by comparison -- it has zippo protecti
Has anyone done any performance studies on zlib? Decompression is OK, but
compression is very, very CPU intensive. I did a study a while back to
investigate using zlib for blobs. The short answer is that it was much,
much faster to read the extra pages than pay for zlib compression and
decompres
No for all questions. The record is a) run length encoded and b) contains
a format version number that must be looked up in rdb$formats.
On Sunday, November 30, 2014, Stuart Simon wrote:
>
>
> On Sunday, November 30, 2014, Stuart Simon > wrote:
>
>> Hello Firebird Developers:
>> Pardon me, bu
rom computing the discrete logarithm
>2. The hashing step currently defined as a two-step SHA1 in RFC 2945
>must be replaced with at least PBKDF2, bcrypt, or scrypt, with an
>appropriate iteration count / tuning parameters to deter from dictionary
>attacks
>
> ht
Uh, if you made it type-safe in the first place, you would need casts.
Think about that over and over until you get it -- if things are declared
and used properly, you never need casts.
Artificial types (used in moderation) eliminate most problems and make the
code easier to understand.
On Thurs
I agree. That's how you understand it. But you are wrong.
On Thursday, December 25, 2014, Dimitry Sibiryakov wrote:
>Ok, let me simplify the question:
>
>I've created an engine that cannot work with databases, created by
> standard engine.
> Standard engine CAN work with databases crea
Why not require things that are potentially case sensitive to be in quotes?
On Tuesday, December 30, 2014, Alex Peshkoff wrote:
> On 12/30/14 02:15, Daniel Rail wrote:
> > Hi,
> >
> > At December 29, 2014, 7:00 AM, Adriano dos Santos Fernandes wrote:
> >
> >> About config keywords using OS case
Surely there is a transaction id info clumplet that will need to be
finessed...
On Thursday, January 15, 2015, Paul Beach wrote:
> < old), or this will break the old API?>>
>
> The API is completely unaffected by the support for 64bit transaction ids.
>
> Regards
> Paul
>
>
> ---
This sounds quite a bit like the circumstances that caused Torvalds to dump
Bitkeeper and write git.
Open source dependent on a private tool is a contradiction in terms.
If he hasn't already, I suggest that Adriano submit his tool to the
Firebird tree now or that Firebird find a different way to
An exception to isc_receive with a null status vector should blow the
program out of the water.
On Saturday, January 31, 2015, Egor Pugin wrote:
> Hi!
>
> build_msg -D msg.fdb -P ./ -F firebird.msg -L all
> when msg.fdb is absent will result in infinite loop.
>
> I have the simple fix - try to
WhatbI have done on other database systems, and it has worked very well, is
allow authorized roles for a user to be assumed and dropped at anytime
during a connection. Access to an object is allowed if the access is
allowed in any of the active roles. There is also a mechanism to state
which roles
On Thursday, February 19, 2015, Thomas Steinmaurer
wrote:
> Jim,
>
> >
> http://www.cio.co.uk/insight/data-management/jim-starkeys-nosql-low-down-it-wont-solve-big-data-3598479/
>
> What do you think about "tunable consistency" instead of "eventual
> consistency"?
>
>
> http://www.datastax.com/do
I'm been using a self-describing value encoding for a decade and a half.
It's denser and cheaper to compress and decompress than the existing run
length encoding, though I'm not sure that compressing version delta would
be a lot of fun, but probably some clever fellow can think of a good
algorithm.
Guys, this is a little crazy. When the reference count goes to zero, the
object goes away. That's the point of reference counting. If an object is
reference counted, it shouldn' have a destroy method or a public destructor.
And, of course, a provider has exactly the same semantics as the Y-valv
--
> Address:
> Elekt Labs s.r.o.
> Chaloupky 158
> 783 72 Velky Tynec
> Czech Republic
> ---
> Mobile: +420 724 207 851
> icq:199 118 333skype:skopalikse-mail:skopa...@elektlabs.cz
> http://www
Elekt Labs s.r.o.
> Chaloupky 158
> 783 72 Velky Tynec
> Czech Republic
> -------
> Mobile: +420 724 207 851
> icq:199 118 333skype:skopalikse-mail:skopa...@elektlabs.cz
> http://www.elektlabs.cz
>
> On 23.2.201
going to ask to sort million character fields. But
it would be nicer to try.
On Monday, February 23, 2015, Adriano dos Santos Fernandes <
adrian...@gmail.com> wrote:
> On 23/02/2015 16:36, James Starkey wrote:
> > Encode null as a value type and skip the null flags altogether --
&
On Monday, February 23, 2015, Slavomir Skopalik
wrote:
> On 23.2.2015 20:36, James Starkey wrote:
> > Encode null as a value type and skip the null flags altogether -- saves a
> > couple of bytes for every record.
> I think to use flags only for nullable fields.
> In this ca
Could you describe what you are actually trying to do rather than how a
possible solution might work? It's a lot easier to work from an actual
problem than to reverse engineer from a murky proposal.
On Thursday, February 26, 2015, Carlos H. Cantu
wrote:
> I would like to start a discussion to
If there's a bug, the correct response to to fix it, not invent yet another
feature to work around the bug.
A correctly code application should get events. The mechanism is designed
to eliminate race conditions. But if you don't understand how it's
supposed to work, it's straightforward to write
Carlos, again, why not figure out why events aren't working at your site.
It is a mechanism designed from the beginning to do what you want,
e.g. notify other connections of a database state change.
What you are suggesting will introduce far more problems than it purports
to solve.
If there is is
No, I don't see. What you want to do, and you agreed, could be done with
the existence ng event mechanism if yiu could figure out why sometimes it
appeared that events weren't being delivered. Instead, your proposing a
whole new class of trigger that would require yet another interface, a
mechani
The answer to your questions is simple: It is much faster to encode from
the original record onto the data pages(s), eliminating the need to
allocate, populate, copy, and release a temporary buffer.
And, frankly, the cost of a byte per full database page is not something to
loose sleep over.
The
-> thats way I
> was did it.
>
> You proposal will needs much more works.
> From my point of view, isn't realistic to do it into FB2.5x or FB3.
> When encoding will be implemented, will be nice to use it also for backup
> and wire protocol.
>
> Thank you for.
>
----------
> Mobile: +420 724 207 851
> icq:199 118 333skype:skopalikse-mail:skopa...@elektlabs.cz
> http://www.elektlabs.cz
>
> On 27.2.2015 19:14, James Starkey wrote:
>
> Perhaps a smarter approach would be to capture the ru
from machines and laboratories
> by means of system MASA (http://www.elektlabs.cz/m2demo)
> -
> Address:
> Elekt Labs s.r.o.
> Chaloupky 158
> 783 72 Velky Tynec
> Czech Republic
>
This was a follow up to a problem I raised to another proposal. I thought
the context was clear, bu apparently not... So here's the context.
Data compression has a huge effect on performance. Reducing the physical
size of the data reduces database size and the number of pages to be read
to fetc
On Mon, Mar 2, 2015 at 8:35 PM, Slavomir Skopalik
wrote:
> Hi all,
> after discusion with Jim, I was created frist draft of proposal for
> value encoding.
>
>
>
> Any comments?
>
>
[Second attempt; first bounced because of size]
Attached is the EncodedStream class from AmorphousDB as an example
A DBKEY is a concatenation of one or more
pairs.
Has anyone considered a global replace of "relation" by "table"? Relation
is not only archaic but mathematically incorrect. In Codd's model,
relations were sets and consequently could not have duplicate rows. No
"relational" database every imple
There is no reason you can't do exactly what you want. Most people
familiar with git tend to use a single repository with multiple branches,
but either works. Multiple branches will consume more disk space, but in
this day and age, who cares?
A note about cmake, git, and MSVS: If git merges a cm
I didn't know about that. I'm in love!
On Tuesday, March 10, 2015, Ivan Arabadzhiev wrote:
> Personally, I used https://code.google.com/p/gitextensions/ back when I
> was on a Windows/VS environment, and was really happy with it.
>
> 2015-03-10 15:37 GMT+02:00 Michal Kubecek >:
>
>> On Tue, M
I wouldn't get excited about TPCC / DBT2 either way. It's a remarkably
stupid benchmark designed to show that partioning is the only way to go.
It is full of idiotic assumption and horrible technology. It assumes, for
example, that everything a customer orders can be serviced from a single
wareho
Indeed. The GPL is pathological. Sun developed a fantastic file system
called ZFS and released under a Sun open source license that requires, like
the Firebird licenses, that modifications be available under the same
license. But Linux integration would require some mods, the mods would
have to
I'd like to see some numbers computed from an actual (real) Firebird
database before it is considered.
But why records only over 4k? And what commonality do you expect to find
on large records?
On Monday, March 16, 2015, Slavomir Skopalik wrote:
> Hi Jim,
> I made some research about storage c
ry it. Three forths of rhat work, however, would be in
abstracting and encapsulating SQZ, which is well worth doing (and
commiting) even if lz4 doesn't pan out.
On Monday, March 16, 2015, Alex Peshkoff wrote:
> On 03/16/15 19:42, James Starkey wrote:
> > I'd like to see some
The problem with specialized processors is that they are a scarce resource
that must be managed rather than shared. They're just dandy when a server
has a single specialized load, but on a server with multiple clients, one
guy gets the specialized processor and everyone one else waits.
The best w
I think it would be extremely difficult to implement both fine grain
multi-threading and co-processor exploitation in a shared meta-data
implementation. If Firebird were rearchitected so that each connection had
a dedicated metadata cache (and the caches with a mechanism to propagate
metadata chan
le that everyone else wants out of the
office (telephone sanitizers, in short) than the best and the brightest.
On Friday, March 20, 2015, Egor Pugin wrote:
> Hi,
>
> What about just "The power of C++11 in Firebird" ?
>
> On 20 March 2015 at 23:44, James Starkey >
The classical mechanism is to establish one range for systen define codes
and another for private extensions.
As has beeb pointed out, any engine or transport can safely ignore
unrecognized codes. Part if the architecture long before Firebird and
Interbase existed.
For those newbies, the Firebir
>
> https://www.visualstudio.com/en-us/products/visual-studio-community-vs
>
> On Fri, Mar 20, 2015 at 11:19 PM, Egor Pugin > wrote:
>
>> Hi,
>>
>> What about just "The power of C++11 in Firebird" ?
>>
>> On 20 March 2015 at 23:44, James St
On Saturday, March 21, 2015, Thomas Steinmaurer wrote:
> >
>
> IMHO 99% of the Firebird customer-base isn't in the "distributed system
> business", thus state-of-the art scale up (instead of scale out)
> capabilities on a single server will be excellent.
> Scale up is a very bad strategy for an
Goal: Morph Firebird into a high performance, distributed, fully redundant
database.
Both JRDs (DEC Rdb/ELN and Interbase) were designed as elastic database
systems for VAXClusters. They are share-nothing engines, communication
exclusively through a distributed lock manage and network attach dis
Attached is the EncodedStream class from AmorphousDB as an example of what
I've been talking about. The module has types that Firebird doesn't need
and is certainly missing types that Firebird needs, but it demonstrates
what I've been talking about. Please note that it has not been licensed as
op
So let me get this straight. Your "everything wrong" with DPBs boils down
to the absence of a comment in a header? Oh, dear me, that is indeed a
deep and grevious fault.
I certainly don't pretend to speak for the rest of the project, but if you
want to add a comment to dpb.h (or whatever), you m
antos Fernandes
wrote:
> On 22-03-2015 13:01, James Starkey wrote:
> > So let me get this straight. Your "everything wrong" with DPBs boils
> > down to the absence of a comment in a header? Oh, dear me, that is
> > indeed a deep and grevious fault.
> >
>
> With FB 2.5.2 SC 64-bit on Windows 7 Prof.
>
> While copying a 18GB database from folder A to B on the same spinning
> physical disk at ~33MB/s read + ~33MB/s write, thus 66MB/s total, doing
> a select count(*) on that database (8K page size) for a table with ~6Mio
> records at a physical disk re
milliseconds (on a good and lucky day). So many
fewer I/Os and much faster I/Os.
The tricky parts all revolve around the issues of multiple/page lock
servers and have almost no effect on the Firebird engine, per se.
Questions? Brickbats? Rebuttals?
On Sunday, March 22, 2015, James Starkey wrote
No. The page/lock server is deeply involved with the Firebird on disk
structure.
On Monday, March 23, 2015, Tony Whyman
wrote:
> Just out of interest, is OCFS2/DRBD any use as a page/lock server?
>
> On 23/03/15 13:01, James Starkey wrote:
> > The major new piece is a separate
Why not just establish a mechanism for other providers to register their
dpb codes. It isn't like their is either a shortage of unused codes or a
large number of new providers. That would also provide an opportunity to
discuss and possibly improve a proposal.
I can't help but think that people a
As written, it did cyclical translation of environmental variables and
symbolic links looking for node names and files on NFS mounted file systems.
On Monday, April 20, 2015, Adriano dos Santos Fernandes
wrote:
> On 20/04/2015 11:08, Dimitry Sibiryakov wrote:
> > 20.04.2015 15:54, Adriano dos Sa
The SQL standard, and Ann will correct me if I'm wrong, is both clear and
simple. Unquoted (and necessarily ASCII) identifiers are folded to upper
case and quoted identifiers are not.
The SQL language character set is ASCII except for strings enclosed in
quotes.
Other than folding ASCII lower ca
I suggest you learn C. It's a very easy, simple language. It should only
take you a few hours and will save many times that down the road. In any
case, you will need to understand both C and the debugger to debug your
code.
Yes, Firebird is now officially C++, but probably closer to C+ in most
Why not just go for 32 bit lengths and stop worrying about it. 16 bit
lengths made a lot of sense on pdp-11s, but those days are long gone.
On Wednesday, July 15, 2015, Adriano dos Santos Fernandes <
adrian...@gmail.com> wrote:
> Hi!
>
> Looking again, Ivan Přenosil may be right and string liter
I don't believe it is "effectively limited" to 20 bytes. This was a
documentation error based on a profound misunderstanding of the SHA-1 hash
function.
On Thursday, July 23, 2015, Stefan Heymann wrote:
> In the FB3 Release Notes the chapter about "Increased Password Length"
> speaks of a maxim
Get real. Read about the actual problems. Bthe issue is that there is a
theoretical problem that a manufactured duplicate collision could be
manufactored in something like time 2^82, something that nobody has
actually be able to do.
Sure, SHA-1 has a known weakeness. It's replacement probably ha
On Sunday, July 26, 2015, Jiří Činčura wrote:
> > Personally, I've recently started using (mostly for kicks) things like
> > https://en.wikipedia.org/wiki/Scrypt
> > https://en.wikipedia.org/wiki/Bcrypt
> > https://en.wikipedia.org/wiki/PBKDF2
> > I suppose the option to tune them in the future (
Sorry, you got taught wrong. Security is about the whole system, not one
piece. Hash based security is vulnerable during password exchange, which a
slow hash doesn't fix.
Internet connections typically pass through a dozen routers, any of which
could be configured to mount a man in the middle at
On Monday, July 27, 2015, Alex Peshkoff wrote:
> On 07/26/2015 10:00 PM, Ivan Arabadzhiev wrote:
> > Personally, I've recently started using (mostly for kicks) things like
> > https://en.wikipedia.org/wiki/Scrypt
> > https://en.wikipedia.org/wiki/Bcrypt
> > https://en.wikipedia.org/wiki/PBKDF2
>
On Wednesday, August 19, 2015, Mark Rotteveel wrote:
>
> >
> > In the final analysis, hardening any computing systems requires that the
> > most vulnerable links be addressed first. In Firebird, that is the use
> > of human chosen passwords.
>
> Using a client-side password vault is an interesti
On Thursday, August 20, 2015, Michal Kubecek wrote:
> On Wed, Aug 19, 2015 at 02:55:33PM -0400, Jim Starkey wrote:
> >
> > The best alternative to RC4 is AES-128. It is "more" (but not
> > measurably) secure but also a couple of hundred times as expensive to
> > compute. If you don't believe me
On Thursday, August 20, 2015, Mark Rotteveel wrote:
> On Wed, 19 Aug 2015 18:17:03 -0400, James Starkey >
> wrote:
> > A "better" hashing algorithm has no signficant effect. The difference
> in
> > security between a 20 byte hash and a 64 byte hash is 1 / 2
On Thursday, August 20, 2015, Alex Peshkoff wrote:
> On 08/18/2015 12:22 AM, Jim Starkey wrote:
> >
> > Unless it can be guaranteed that SRP verifiers in Firebird are immune
> > to compromised
>
> What do you mean by 'immune to compromised' here? The main goal of using
> SRP as a default authenti
On Thursday, August 20, 2015, Tommi Prami wrote:
> Just my 0.02€
>
> http://ianix.com/pub/chacha-deployment.html
>
> ChaCha20 is in TSL and OpenSSH etc. and mainly because it is secure and it
> is fast.
>
>
> I wasn't aware of that. Very, very cool.
--
Jim Starkey
On Thursday, August 20, 2015, Alex Peshkoff wrote:
>
>
> And what about the vault at the client side containing long randomly
> generated password for SRP - this is definitely a way to make things not
> as bad as they can when verifiers are compromised. I suppose to use this
> suggestion in post-
I'm curious about how important people consider on-disk encryption to be.
I have two questions.
First question: On a scale from 1 (don't care, wouldn't use it) to 5 (I
need it yesterday) how important to us is the ability to encrypt database
files. Assume a bobust encryption scheme and a moderate
On Friday, August 21, 2015, Scott Morgan wrote:
>
> Q1 : 4, I don't expect NSA defeating crypto[0], but enough to keep
> casual eyes away from expensive data.
>
> Q2 : 5, It's a must. Whether the key is somehow held internal to the
> .FDB file (with it's own pswd, no system wide account access, n
On Saturday, August 22, 2015, Brian Vraamark
wrote:
> On windows you can use DPAPI. I don't know if Linux (and other systems)
> has something similar (maybe Gnome-Keyring?).
>
>
I have a strong preference for portable, transparent solutions. In theory,
Microsoft has the same problem that unatten
One of the tenants of moderm cryptology is that algorithms and mechanisms
have to be published for analysis and review. The basic idea is that
security is based on a mathematical impossibility that a cryptosystem cabe
be broken within the time remaining in the universe. The once dominant
idea was
1 - 100 of 125 matches
Mail list logo
