Dalton Calford wrote:
[...]
> As I have stated in multiple posts - I am not looking for the
> authentication/authorization/encryption layer to be complete,
> just a parser change. In the same vein as "COMMENT ON"
> replaced "UPDATE RDB$ SET RDB$DESCRIPTION=..." .
Having slept on it (which
I misunderstood what you meant by "custom embedded tool" and
connecting directly to the database. It sounds like you're
talking about a custom-built version of Firebird that they load
onto the machine (somehow?), do what they need to do, and then
unload before they go (presumably wiping up after t
Hi Geoff,
You must have missed the part about the developer using a custom embedded
tool ie, not going through the server but touching the database directly.
Using custom embedded tools for such work is quite common and if the
developer leaves that tool in the clients control when they are not wor
Dalton Calford wrote:
[...]
> What it does mean, is that if someone tries to connect to a
> database that is fully encrypted and their client does not
> securely pass the decryption key to the server, the server
> will just come back with an error about the database being
> corrupt or some other ag
04.09.2014 19:25, Tom Coleman wrote:
>
> Speaking of the v3.0 release, who updates 3.0 Beta 1 release dates?
Me.
> August 31 has come and gone:
I know.
> Are there really just 5 unresolved issues delaying the beta release?
Yes, around that number.
Dmitry
---
I don't necessarily disagree with you, but what you suggest requires
major design, buy in, and implementation, none of which are remotely
possible in the available time.
Encryption is all about key management which is not simple and if isn't
correctly designed and implemented, is useless. It
Hi Geoff,
If you notice at the end of my first posting, I said the
encryption/decryption/authorization could wait for later implementation and
the new DDL statements that happen to deal with the rdb$source fields would
just delete the source - ie provide the same functionality.
The existing behav
On Sep 4, 2014, at 11:17 AM, Geoff Worboys wrote:
> Dalton Calford wrote:
>> I still argue that we should take the opportunity to not only
>> fix this issue, but to improve the FB product functionality.
>
> Part of the problem is the timing. How much do the Firebird
> developers really want to
Hi Jim,
If the on disk database is encrypted, and the end user is only provided
enough credential keys to see what the application developer wants them to
see, then, the information remains secure.
The assumption on my part is that some elements of the database such as the
DDL descriptions, sourc
Dalton Calford wrote:
> I still argue that we should take the opportunity to not only
> fix this issue, but to improve the FB product functionality.
Part of the problem is the timing. How much do the Firebird
developers really want to implement right now before v3.0
release.
Another part is that
If the on disk file is encrypted as stated in my discussion, and the sysdba
is limited or prevented from connecting as also stated, then this will run
on a non-controlled environment.
The question is, what level of encryption is needed? You can encrypt the
entire database, certain pages of the d
Dalton, it's theoretically impossible to hide something with system
privileges and without encryption on an open source product. All that's
necessary is for someone to compile a version without checks. Now, it
is true that we're only trying to protect the "source" from people too
ignorant or
04.09.2014 16:49, Dalton Calford wrote:
> So, DDL statements such as GRANT VIEW which is used by MS SQL for metadata
> security could
> be applied to FB.
No, they couldn't unless Firebird is run in controlled environment which is
not the
case of topic starter.
--
WBR, SD.
-
I still argue that we should take the opportunity to not only fix this
issue, but to improve the FB product functionality.
The core requirement is to stop non-authorized users from viewing source
code. The current process is to delete the source code from the database.
There is also the common
I think we already reached a point where core developers can hit the
hammer in what will be the chosen "solution" of this problem in FB 3.
I would be satisfied with either relaxing rules in
rdb$triggers/procedures, or with new syntax, or with last Jim's
proposal of SET statement. I'll leave this to
On 02/09/2014 02:42, Dmitry Yemanov wrote:
> Agreed wholeheartedly. The point was that it restores exactly what was
> possible prior to v3 without compromising the system tables protection
> and that it's easy (if not easiest) to implement. I didn't pretent it
> looking elegant.
>
>
Not only the
Another possible solution: a set statement that controls the state of the DDL
engine to save source or not (defalut is save). Essentially the same as the
dpb item but syntax. The positive is that it doesn't mess with the syntax of
already complex declarations and needs only appear once in a sc
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.
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 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
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
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
> 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
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.
--
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
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
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
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 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 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 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
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.
---
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
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
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
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.
--
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
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 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
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
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
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
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?..
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
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.
>
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
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
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 (
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
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
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 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
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 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
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
>> 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
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
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 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 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 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 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
I got errors returns from the email server so I'm re-sending:
Jim, your latest posting does not help the current situation.
It only complicates the discussion unnecessarily.
The immediate problem, and the only one that needs immediate discussion
on this list, is how to re-instate the functionalit
schedule is not delayed unduly.
Discussion of the larger issues can be done afterwards. On the
architecture list.
On 2014-08-31 18:04, firebird-devel-requ...@lists.sourceforge.net wrote:
> From: James Starkey
> Subject: Re: [Firebird-devel] Hiding source code of procedures and
> trig
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 interests
> of its users
On Aug 31, 2014, at 9:39 AM, James Starkey wrote:
> This calls into question whether Firebird exists to serve the interests of
> its users or just for the amusement of certain dilantants.
Jim's often prescient comments sent me to the dictionary to look this one up.
Per Webster:
dil·et·tant
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 to maintain currently behavior, it doesn't matter who
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
31.08.2014 15:51, Carlos H. Cantu wrote:
>
> We have a "hack" that many people uses for a long time, to make it
> more difficult to stole procedures/triggers source (more difficult,
> not impossible, since BLR can be decoded to source). They know it is
> not 100% safe, but so far it is the only wa
Adriano dos Santos Fernandes wrote:
> On 31-08-2014 12:06, Geoff Worboys wrote:
>>
>> I'd like to argue that developers have already had years to
>> find a better solution than deleting the source, but really the
>> only better solution is UDR, and developers need significant
>> time to migrate. S
Mark Rotteveel wrote:
> On 31-8-2014 17:06, Geoff Worboys wrote:
>> I still haven't forgiven Firebird for the abrupt change of
>> alias ambiguity rules from v1.5 to v2.0. The particular
>> circumstances of the time meant that this was hugely
>> inconvenient to one of my largest projects. Had some
On 31-8-2014 17:06, Geoff Worboys wrote:
> I still haven't forgiven Firebird for the abrupt change of
> alias ambiguity rules from v1.5 to v2.0. The particular
> circumstances of the time meant that this was hugely
> inconvenient to one of my largest projects. Had some migration
> mechanism been
On 31-08-2014 12:06, Geoff Worboys wrote:
>
> I'd like to argue that developers have already had years to
> find a better solution than deleting the source, but really the
> only better solution is UDR, and developers need significant
> time to migrate. So if you want projects to stay current, y
James Starkey wrote:
> [...]
> Carlos has enumerated a set of acceptable possibilities, none
> of which is overwhelming difficult. I can see no constructive
> reason why his request should not be accomodated other than
> contempt for users.
Despite my objections to the technique (that it could, q
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
On 31-8-2014 13:51, Carlos H. Cantu wrote:
> Let's get back to the facts and try to reach a decision:
>
> We have a "hack" that many people uses for a long time, to make it
> more difficult to stole procedures/triggers source (more difficult,
> not impossible, since BLR can be decoded to source). T
31.08.2014 13:51, Carlos H. Cantu wrote:
> As pointed before, databases with procs/triggers with null source can
> be restored in FB 3 without any problem, but you can't erase the
> sources anymore. This looks inconsistent.
>
> Proposals so far:
>
> 1) Create an official way to make the source null
Let's get back to the facts and try to reach a decision:
We have a "hack" that many people uses for a long time, to make it
more difficult to stole procedures/triggers source (more difficult,
not impossible, since BLR can be decoded to source). They know it is
not 100% safe, but so far it is the o
Thomas Beckmann wrote:
> As it has been pointed out, erasing source is a familiar way
> to obfuscate source code, we have been using this from time
> to time ourselves. Moreover, you can restore an FB2-DB
> without sources to a working FB3-DB, but you can not create
> it by FB3 natively - that's i
Am 29.08.2014 14:53, schrieb Dimitry Sibiryakov:
> 29.08.2014 14:47, Carlos H. Cantu wrote:
>> You can ask them:)
>
>Actually, they have to ask themselves if the sources are precious enough
> to waste time
> for their protection. AFAIK, database itself is usually pointless without
> applica
On 30 August 2014 21:08, Dimitry Sibiryakov wrote:
>
> 30.08.2014 8:15, Thomas Beckmann wrote:
> > The main point is: We want FB3 to spread fast and easily.
>
>But I would like Firebird to attack rather enterprice level than poor
> low-end.
>
> How about both !! - many successful projects ha
30.08.2014 8:15, Thomas Beckmann wrote:
> The main point is: We want FB3 to spread fast and easily.
But I would like Firebird to attack rather enterprice level than poor
low-end.
--
WBR, SD.
--
Slashdot TV.
Vid
Am 29.08.2014 14:18, schrieb Dimitry Sibiryakov:
> 29.08.2014 13:57, Carlos H. Cantu wrote:
>> The matter is that most companies who uses FB in Brazil are really
>> small. Some one them has only one developer. Changing to UDR may
>> require big changes in the way those companies updates and maintai
2014-08-29 17:51 GMT+04:00 Dalton Calford :
> This issue could be solved by extending the GRANT/REVOKE DDL syntax such as
> adding a VISIBLE [AS NULL] option to the privileges list - ie if you revoke
> visible from a column, it is as if that column does not exist. If you
> revoke visible with th
Carlos H. Cantu wrote:
> So far, there is no official way to hide procedures and
> triggers source code (protecting intelectual property). The
> technique of updating system tables writing "null" to the
> source code is used by a lot of people, since it seems to be
> the only way to have some kind
Anyone who's followed the support list for a decade or so knows that developers
frequently ask how they can protect the source of their procedures. And,
likewise, that the answer is that the esssence of the procedure is the BLR and
must be readable to be used, so the best option is to mask the
As an extrapolation of my last post,
The idea of extending the grant revoke syntax vs allowing for removing the
code from the system tables assumes a few things.
1.) It assumes enhanced user authorization options and control
2.) It makes the assumption that since blr can be reversed and encrypted
On 29 August 2014 08:53, Dimitry Sibiryakov wrote:
>Actually, they have to ask themselves if the sources are precious
> enough to waste time
> for their protection. AFAIK, database itself is usually pointless without
> application that
> works with it.
>
>
Not always true.
I have databases t
29.08.2014 14:47, Carlos H. Cantu wrote:
> You can ask them:)
Actually, they have to ask themselves if the sources are precious enough to
waste time
for their protection. AFAIK, database itself is usually pointless without
application that
works with it.
--
WBR, SD.
--
DS>How much money they will loose if someone see the sources of their
source procedures?
You can ask them :)
Sorry, I need to go now.
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
DS> 29.08.2014 13:57, Carlos H. Cantu wrote:
>> The matter is that most compani
29.08.2014 13:57, Carlos H. Cantu wrote:
> The matter is that most companies who uses FB in Brazil are really
> small. Some one them has only one developer. Changing to UDR may
> require big changes in the way those companies updates and maintain
> their softwares (this means cost).
How much mo
DS>Is it too high price for protecting your copyrights?..
The matter is that most companies who uses FB in Brazil are really
small. Some one them has only one developer. Changing to UDR may
require big changes in the way those companies updates and maintain
their softwares (this means cost).
29.08.2014 13:12, Carlos H. Cantu wrote:
> Afaics, UDR is new feature, and add extra complexity compared to
> creating and maintaining procedures/triggers direct in the database
Is it too high price for protecting your copyrights?..
--
WBR, SD.
>> As already Robert said: FB 3 provides UDRs. If someone want to hide
>> sources - use them.
AP> Certainly it's the good solution.
Afaics, UDR is new feature, and add extra complexity compared to
creating and maintaining procedures/triggers direct in the database
(thing that most people are
On Fri, 29 Aug 2014 14:53:14 +0400, Alex Peshkoff
wrote:
> On 08/29/14 14:43, Mark Rotteveel wrote:
>> What does that mean? On the fly/on demand compilation from source, or
>> using a different byte code representation than blr?
>
> Compilation from source directly into executable by engine form.
29.08.2014 12:48, Alex Peshkoff wrote:
> On 08/29/14 14:26, Dimitry Sibiryakov wrote:
>> The rest of users can live with sources accessible by owner/DBA only.
>
> Do not know how is it related with hiding sources.
There are two kind of users: trustworthy DBA and coward malefactors. The
former
On 08/29/14 14:43, Mark Rotteveel wrote:
> On Fri, 29 Aug 2014 14:12:12 +0400, Alex Peshkoff
> wrote:
>>> That sounds like an idea. An alternative would be to allow this when
>>> creating or altering the procedure, eg something like CREATE PROCEDURE
>>> myprocedure(...) RETURNS ... WITH (SUPPRESS_
On 08/29/14 14:26, Dimitry Sibiryakov wrote:
> 29.08.2014 12:18, Alex Peshkoff wrote:
>> On 08/29/14 13:51, Dimitry Sibiryakov wrote:
>>> 29.08.2014 11:19, Alex Peshkoff wrote:
Why? If decrypt key is present only at developer's server - it's not bad
solution.
>>> Too complicated, IM
On Fri, 29 Aug 2014 14:12:12 +0400, Alex Peshkoff
wrote:
>> That sounds like an idea. An alternative would be to allow this when
>> creating or altering the procedure, eg something like CREATE PROCEDURE
>> myprocedure(...) RETURNS ... WITH (SUPPRESS_SOURCE) AS ...
>
> Like Dimitriy correctly noti
On Fri, 29 Aug 2014 07:11:38 -0300, "Carlos H. Cantu"
wrote:
> MR> Personally I don't see the point. I also wonder how many people
> actually
> MR> use this loophole; you say "a lot". In my vocabulary that means more
> than
> MR> two; or in other words: it is not a solid basis for a decision.
>
>
1 - 100 of 113 matches
Mail list logo
