Martin Bartosch wrote:
admin 1 requests operation X on object A
-> results in an entry in edit state
Now as long as the request is neither approved nor revoked it is not
possible (it SHOULD not be possible) to add a new (conflicting)
change request for the same object. That would mean two active
ch
Michael Bell wrote:
Next question is the new state. If we start approving a pending request
then this request is no longer pending and it is not approved. There is
hmm, but it is actually pending, till all necessary operators have given
there statement... for the object - its still in pending st
Hi,
>> requests that blocked others, but believe me, in field usage it pays
>> to have a design that does not allow for inconsistent data.
> how can one request block another?
admin 1 requests operation X on object A
-> results in an entry in edit state
Now as long as the request is neither appr
Martin Bartosch wrote:
nope, note the 1:n in front of action. One entry for each admin.
yeah, i think thats clear ;) - i maybe didn't rewrite this so clear
IMO we should really prevent having more than one object floating
in edit state at any time. This problem always comes up with dual
control.
no
Obes, Til wrote:
So again ;)
Whats now with moving the translation to the database too?
The utf-8 thing was one point against it. Its fixed/solved.
So anything against it? (possible bugs dont count)
now, i still like the idea, but there are others ;)
which don't?
greetings
dalini
--
> I commited some minutes ago the migration stuff to UTF-8. The only
> remaining issue is the compilation of new mo-files. I didn't do this
> because surprisingly the most .po files are in UTF-8 format.
> So perhaps
> I made a mistake some time before.
>
> cd src/common/lib/locale/pot; make
>
Hi,
>> My idea was this one:
>> object -- 1:n -- action -- 1:1 -- signature
>
> there i would have some questions:
>
> - which signature would stand in the end
>
> and
>
> - then, it is not clear anymore who did which action
> - and the operator may not be 'liable' for it since
>
Hi,
short notice, the voting process (if present) of the last state change
must always be present. This is necessary for example to protect an
approved request against manipulations even on the online interface.
Michael
--
___
Michael B
Hi Martin,
Schema and stuff sounds like a good idea. Wiki, anyone...? :-)
I think MoinMoin also supports online drawing of diagrams.
Might be useful and productive that way, but that's just an idea.
I found a software called dia. There are two good things on dia - first
I can write ER diagrams now
Hi,
I commited some minutes ago the migration stuff to UTF-8. The only
remaining issue is the compilation of new mo-files. I didn't do this
because surprisingly the most .po files are in UTF-8 format. So perhaps
I made a mistake some time before.
cd src/common/lib/locale/pot; make
After this st
Hi,
>> This is how we did it in the other project. The approach is very
>> clean but unfortunately not very easy to implement.
>> (We also had some performance issues in a later stage, but this
>> was because each and every object in the system had an 'edit' table
>> that was used to hold modifica
Oliver Welter wrote:
Hi Martin,
Ouch...
I see some problems on writing confident material on the disk because
even on *nix'es you can try to recover files - I had this idea some time
ago: Whats about creating a special Ram-Disk or Crypto-Loop device to
use as temporary "file" storage ?
i think
oh, just as we talking about database desing in relation to sign actions
and state changes:
do we have an option to create request objects, which just have a dn and
a pwd (pre shared secret) stored? (which also may have been signed,
means pre approved by 1:n operators?)
this is necessary for
So what you propose is:
-- 1:1 -- Action
Object -- 1:n -- Approval -- 1:1 -- Action
-- 1:1 -- Action
All in one line:
object -- 1:n -- approval -- 1:n -- action ?
My idea was this one:
object -- 1:n -- action -- 1:1 -- signature
there i would h
Hello!
>
> Does this solve perhaps all known issues? We simply switch to UTF-8. If
> we make OpenCA an UTF-8 only application then there should be no longer
> any open issues with i18n, SQL databases and HTML representation.
>
> Comments about this? Martin, Janez?
Yes, this sounds like a good
Hi Martin,
- currently it is only possible to get the own CA certificate from
the DB, isn't it? The var/crypto/chain directory may contain
the required certificates, but it is not really enforced, right?
Do you think it is sensible to construct the keystores based
on the CA certs that are a
Hi M's,
Martins idea is a good approach but I am not a fan of copiing over stuff
to a second datebase and remerging it afterwards - my idea:
I assume, that we dont have to approve complex editing on the request
but only simple state-changes - this means that is not possible to edit
for example
Hi Michael,
> iconv
> Does this solve perhaps all known issues? We simply switch to UTF-8. If
> we make OpenCA an UTF-8 only application then there should be no longer
> any open issues with i18n, SQL databases and HTML representation.
>
> Comments about this? Martin, Janez?
this sounds good. I'
Hi,
I am currently implementing two new features and would like to discuss
some issues about this:
1. Java keystore download (RFE 1009969)
I have implemented a Java tool that allows to create Java keystores
on the command line.
Required input (currently):
- End entity certificate (DER format)
-
Michael Bell wrote:
Future
--
The optimal solution would be if we have only to deal with UTF-8. This
means the user would only receive HTML data which is UTF-8 encoded. The
databases would be happy. Perl is already aware of UTF-8.
The language databases are the biggest problem. There are sev
Hi Martin,
Hmm, the problem is that we have multiple different meanings of
'approval' here. What you are thinking of is
- the object remains unmodified in the database until the completion of
the process
- a number of 'action/operation/transition/modification' entries
are generated by each admi
Hi,
>> -- 1:1 -- Action
>> Object -- 1:n -- Approval -- 1:1 -- Action
>> -- 1:1 -- Action
>
> All in one line:
>
> object -- 1:n -- approval -- 1:n -- action ?
yes, of course. Stupid me. :-) Forget it.
> My idea was this one:
>
> object -- 1:n
action is in my understanding the operation (e.g. approval, deletion)
plus the user information. So perhaps action is the wrong name. Perhaps
the name approval or authorization for all is more correct. Ok, some
definitions:
APPROVED - is a state of OpenCA's object lifecycle
DELETED - is a stat
Hi Martin,
And NO, I do NOT think we will need signing multiple objects, so we
shouldn't bother any longer about this.
Cool, then we can go back to single objects. This makes all much easier
(at minimum for me :) ).
The next question is the signing itself. Would it be a good idea to
create a tabl
24 matches
Mail list logo
