On 09/01/14 01:53, Carlos H. Cantu wrote:
> DY> What about unencrypted distributed databases? Should we care about
> DY> hiding PSQL source also from SYSDBA / DBO? Are there real cases when it
> DY> would be needed?
>
> Well, the currently "hack" makes no distinction of users, so if the
> idea is t
On 08/31/14 23:23, James Starkey wrote:
> 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
> para
On Sun, 31 Aug 2014 18:04:25 -0400, Tom Coleman
wrote:
> I no longer write applications that do not use some form of ORM. The
last
> time I tried to find a JPA solution that worked with Firebird I was
> disappointed.
Could you post some more details about these problems to Firebird-java or
to me
On Mon, 1 Sep 2014 02:48:59 +1000, Geoff Worboys
wrote:
> Hey, it's my grudge, I'll carry it as long as I want! ;-)
>
> More seriously, it didn't come into being until v2.1 did it?
> And was then backported to v2.0. I can imagine the same sort
> of thing happening with this source code deletion
On Tue, Jul 29, 2014 at 11:35:11AM +0300, marius adrian popa wrote:
> Question is on Google + page
>
> https://plus.google.com/b/111558763769231855886/+AchimKalwa/posts/8Pw5p9462Te?cfem=1
>
> I guess it's a lot simpler now to apply the patch if we drop support
> for windowsxp in firebird 3.x
If
On Tue, Jul 29, 2014 at 11:56:49AM +0300, Damyan Ivanov wrote:
> -=| marius adrian popa, 29.07.2014 11:35:11 +0300 |=-
> > Question is on Google + page
> >
> > https://plus.google.com/b/111558763769231855886/+AchimKalwa/posts/8Pw5p9462Te?cfem=1
> >
> > I guess it's a lot simpler now to apply the
01.09.2014 11:24, Alex Peshkoff wrote:
> That's nice - but what should happen with that special syntax when BLR
> follows DYN?
Easy option - deprecate the command.
A more clever one - not DROP (nullify) the source but set some flag to
HIDE it instead. That flag would mean returning NULL instead
On 09/01/14 12:18, Dmitry Yemanov wrote:
> 01.09.2014 11:24, Alex Peshkoff wrote:
>
>> That's nice - but what should happen with that special syntax when BLR
>> follows DYN?
> Easy option - deprecate the command.
>
> A more clever one - not DROP (nullify) the source but set some flag to
> HIDE it i
>> That's nice - but what should happen with that special syntax when BLR
>> follows DYN?
>
>Easy option - deprecate the command.
>
>A more clever one - not DROP (nullify) the source but set some flag to
>HIDE it instead. That flag would mean returning NULL instead of source
>blob for user reques
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
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 will happen if the key is wrong?
What to do if the engine have to read the field for internal needs? For
example, how to
execute a p
Good. Some questions.
If the key is wrong, the engine will return horrible, useless gook. It
would be possible to check for ascii/utf-8, but this would defeat other
uses of the mechanism. So return horrible, useless gook.
Internal use is a very interesting case. In Carlo's case, this never
ha
01.09.2014 15:22, James Starkey wrote:
> But, unless additional work is done, the simple answer is that if you encrypt
> the BLR
> version it won't work at all without the key.
As the result, the efforts to protect database content from stealing leads
to a
database that cannot be used. Secur
James Starkey wrote:
> 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?
[...]
I'm in no pos
01.09.2014 16:01, Geoff Worboys wrote:
> At this late stage of v3.0, it seems to me that simple and
> least possible change (to v3 and to the developer) should
> be high on the list of priorities. More sophisticated
> options could be assessed in detail later.
Exactly for this reasons the opti
No, that's not even close to true. If the only fields encypted were the
procedure and trigger source blobs, nothing would be inaccessible without the
key except those blobs.
Obviously you disagree. Please explain your logic.
> On Sep 1, 2014, at 9:51 AM, Dimitry Sibiryakov wrote:
>
> 01.09
On 01/09/2014 11:14, Jim Starkey wrote:
> No, that's not even close to true. If the only fields encypted were the
> procedure and trigger source blobs, nothing would be inaccessible without the
> key except those blobs.
>
> Obviously you disagree. Please explain your logic.
>
>
Source text is (
How can you make an assessment without taking the time to understand it?
The Achilles heel of open source is the drive to be the first to kill a new
idea or to kill it the deadest. It made progress at MySQL almost impossible.
Even ideas as simple as stabilizing error codes across versions.
Re
01.09.2014 16:14, Jim Starkey wrote:
> No, that's not even close to true. If the only fields encypted were the
> procedure and trigger source blobs, nothing would be inaccessible without the
> key except those blobs.
>
> Obviously you disagree. Please explain your logic.
I'm still thinking
Dimitry Sibiryakov wrote:
> 01.09.2014 16:01, Geoff Worboys wrote:
>> At this late stage of v3.0, it seems to me that simple and
>> least possible change (to v3 and to the developer) should
>> be high on the list of priorities. More sophisticated
>> options could be assessed in detail later.
>
Jim Starkey wrote:
> How can you make an assessment without taking the time to
> understand it?
I understand enough to know that all of the options mean
intercepting reads and/or writes to the source field.
Any form of obscuring encryption you want to add to the
read/write of that field is obviou
01.09.2014 16:35, Geoff Worboys wrote:
> The more Firebird does this, the
> more of a reputation it will get for leaving users behind, and
> the less users will be inclined stay with or come to Firebird.
It may sound scary, but... what other option do they really have?.. Oracle?
PG? MySQL?..
On Mon, 1 Sep 2014 09:22:37 -0400, James Starkey
wrote:
> If the key is wrong, the engine will return horrible, useless gook. It
> would be possible to check for ascii/utf-8, but this would defeat other
> uses of the mechanism. So return horrible, useless gook.
However, what if I want only part
On Mon, 01 Sep 2014 16:47:24 +0200, Dimitry Sibiryakov
wrote:
> 01.09.2014 16:35, Geoff Worboys wrote:
>> The more Firebird does this, the
>> more of a reputation it will get for leaving users behind, and
>> the less users will be inclined stay with or come to Firebird.
>
>It may sound scar
Sorry, if you had been paying attention, you would have noticed that the key
comes from a database parameter block parameter. Really, understand first,
then shoot.
I outlined the code. Maybe two, three hours. Possibly a whole day if it
involves selecting an open source AES function. I descr
01.09.2014 16:57, Mark Rotteveel wrote:
> And you think that is not an option?
Yep.
--
WBR, SD.
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
Firebird-Devel mailing list, web inte
This is an issue (and one that I brought up). I don't think it important.
Somebody does need to specify a key to read an encrypted instance, but while
that key is active, i.e. attachment session, it won't be able to read
unencrypted instances. Personally, I think this is a feature -- differen
01.09.2014 17:04, Jim Starkey wrote:
> This is an issue (and one that I brought up). I don't think it important.
> Somebody does need to specify a key to read an encrypted instance, but while
> that key is active, i.e. attachment session, it won't be able to read
> unencrypted instances. Pers
01.09.2014 17:10, Dimitry Sibiryakov wrote:
>These vendors are too lazy to convert their PSQL routines into UDRs.
BTW, Adriano had no problem with IDL -> C++/FPC translation. I'm sure he can
make PSQL
-> C++/FPC translator as well to offer them a help in securing their precious
code.
--
Jim Starkey wrote:
> Sorry, if you had been paying attention, you would have
> noticed that the key comes from a database parameter block
> parameter. Really, understand first, then shoot.
So? If you had been paying attention, you would have
noticed that I didn't single key management out as the
I think that would do it. Simplest idea so far.
Anybody see any problems with it? Anyone have a simpler solution?
> On Sep 1, 2014, at 11:35 AM, Geoff Worboys
> wrote:
>
> Jim Starkey wrote:
>> Sorry, if you had been paying attention, you would have
>> noticed that the key comes from a da
On 01/09/2014 12:31, Dimitry Sibiryakov wrote:
> 01.09.2014 17:10, Dimitry Sibiryakov wrote:
>>These vendors are too lazy to convert their PSQL routines into UDRs.
>BTW, Adriano had no problem with IDL -> C++/FPC translation. I'm sure he
> can make PSQL
> -> C++/FPC translator as well to
01.09.2014 18:12, Adriano dos Santos Fernandes wrote:
> How many $$ are you going to paying me?
Nothing: I'm proud of my PSQL sources and have to will to hide them. Ask
those Brazil
guys Carlos was referring to.
--
WBR, SD.
---
01.09.2014 18:14, Dimitry Sibiryakov wrote:
> Nothing: I'm proud of my PSQL sources and have to will to hide them.
It should be read as "I have NO wish to hide them".
--
WBR, SD.
--
Slashdot TV.
Video for Ne
-=| Michal Kubecek, 01.09.2014 09:15:33 +0200 |=-
> On Tue, Jul 29, 2014 at 11:56:49AM +0300, Damyan Ivanov wrote:
> > -=| marius adrian popa, 29.07.2014 11:35:11 +0300 |=-
> > > Question is on Google + page
> > >
> > > https://plus.google.com/b/111558763769231855886/+AchimKalwa/posts/8Pw5p9462Te?
01.09.2014 19:58, Jim Starkey wrote:
> Anybody see any problems with it?
I like neither DPB solution because it's DPB. It's not a "connection
string" option, it's an API option. Surely not a problem for ISQL users
that will support it out of the box. But most of existing user
applications need
01.09.2014 20:58, Dmitry Yemanov wrote:
> Relaxed write restriction for rdb$source is probably even easier to
> implement.
But it requires a quite complex condition, no? Not just "if relation is
system one,
throw exception", but "if relation is system one, but not this and that, throw
except
01.09.2014 23:28, Dimitry Sibiryakov wrote:
> But it requires a quite complex condition, no? Not just "if relation is
> system one,
> throw exception", but "if relation is system one, but not this and that,
> throw exception".
Complex condition is: relation is X and no other field but rdb$sourc
01.09.2014 23:35, Dmitry Yemanov wrote:
> Complex condition is: relation is X and no other field but rdb$source is
> modified
and the new value is NULL, of course.
Dmitry
--
Slashdot TV.
Video for Nerds. Stuff tha
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
02.09.2014 00:22, James Starkey wrote:
> What possible user applications are going to be doing procedure and
> trigger definitions that require the source be omitted?
Whatever user application that works with the database and executes
metadata upgrade scripts itself, without invoking ISQL.
> An
01.09.2014 21:35, Dmitry Yemanov wrote:
> Complex condition is: relation is X and no other field but rdb$source is
> modified. We already have function in VIO doing such a check for other
> purposes.
You are not going to simplify code, are you?..
--
WBR, SD.
--
> On Sep 1, 2014, at 4:42 PM, Dmitry Yemanov wrote:
>
> 02.09.2014 00:22, James Starkey wrote:
>
>> What possible user applications are going to be doing procedure and
>> trigger definitions that require the source be omitted?
>
> Whatever user application that works with the database and exec
Dmitry Yemanov wrote:
> I like neither DPB solution because it's DPB. It's not a
> "connection string" option, it's an API option. Surely not
> a problem for ISQL users that will support it out of the
> box. But most of existing user applications need to be
> recompiled to use the new option. Those
02.09.2014 00:59, Dimitry Sibiryakov wrote:
>> Complex condition is: relation is X and no other field but rdb$source is
>> modified. We already have function in VIO doing such a check for other
>> purposes.
>
> You are not going to simplify code, are you?..
Neither of the solutions being discusse
>> 02.09.2014 00:22, James Starkey wrote:
>>
>>> What possible user applications are going to be doing procedure and
>>> trigger definitions that require the source be omitted?
>>
>> Whatever user application that works with the database and executes
>> metadata upgrade scripts itself, without inv
Saunders, Rich wrote Mon, 01 Sep 2014 04:06:24
+0400:
In addition to protecting FB3 procedures, functions and triggers should
also realize and reset the source code of the package body.
--
Simonov Denis
--
Slashdo
02.09.2014 01:23, Jim Starkey wrote:
>
>> Whatever user application that works with the database and executes
>> metadata upgrade scripts itself, without invoking ISQL.
>
> Do you really think there are any? Seriously? Really?
I know that. Also, there are popular ISQL replacements like IBEScript.
48 matches
Mail list logo
