Dealing with the reformat for Simplename
by Adam Young
I think you can work around a reformat this way:
1. Do a reformat of the code prior to the simplename patch and tag it
2. Do a reformat of the code with the simplename patch applied and tag it
3. Generate a patch that is the diff of steps 1 and 2
No guarantees, but it should be pretty much the same to apply the new
patch on top of the reformat as on top of step 1 above.
12 years, 3 months
[PATCH] 9 Added unit tests to measure conversion speed.
by Endi Sukma Dewata
New tests have been added to measure the conversion speed.
Currently the results are not validated, they are used to compare
the performance before and after upgrading to Charset.
Ticket #3
--
Endi S. Dewata
12 years, 3 months
[PATCH] 10 Replaced TreeSet with LinkedHashSet.
by Endi Sukma Dewata
The TreeSet has been replaced by LinkedHashSet because it is used to
store non-Comparable objects according to the insertion order. This
fixes a ClassCastException that happens while viewing Certificate
Revocation List.
--
Endi S. Dewata
12 years, 3 months
patch correcting request and certificate list paging
by Andrew Wnuk
Patch correcting request and certificate list paging.
This patch corrects request list issue related to jumping
to the end of a request list, eliminates option to request
page outside a list limits and provides unified behavior
to request and certificate listing.
Bug #768138.
12 years, 3 months
thinking about searches in the new restful interface
by Ade Lee
Hi all,
I have been thinking about what kinds of searches to (initially) expose
in the new restful interface for keys and keyrequests.
Here is the basic idea:
1. A client (ipa) will store a symmetric key or passphrase with a
specified client ID. For a volume encryption key, this might look
something like "volume-uuid encryption key #1" or "volume-uuid
passphrase #1" for example. Whatever it is, it needs to be something
that the client (IPA) can later use to retrieve the key if necessary.
2. When the key is archived, the drm will return a reference to the key
stored -- > something like https://foo.com/key/0xdeadbeef. IPA can
store this value in its database if it wants to - and use it to later
access the key/passphrase.
3. At some point, someone contacts the IPA admin and requests either a
passphrase or a symmetric key. The admin looks up the volume entry in
the IPA database and sees there is one (or more) passphrases and one (or
more) encryption keys stored for this volume.
4. The admin then requests the recovery of this volume key. If the
number of agents required to approve this transaction = 1, then the
admin receives the relevant key. (I'm ignoring wrapping etc. in this
description).
5. If the number of agents required to approve > 1, then the request is
in pending state.
6. If the request is pending - then other admin(s) can view the request
- and approve it. This approval is sent back to the DRM and the request
state changes accordingly. Once the correct number of approvals is
obtained, the request is moved to approved state.
7. The admin can then recover key/passphrase.
8. If a volume is set out of service/ wiped etc. then the admin
notifies the DRM and deletes the entry from the IPA database. On the
DRM side, the key will either be removed or more likely be marked in the
inactive state.
Based on the scenarios above, I have been trying to determine which
searches the IPA admin might want to be able to do.
Here is what I see so far:
For scenario 6:
GET /pki/keyrequests/pending --> get a list of pending requests.
GET /pki/keyrequests/recovery/pending --> get a list of pending recovery requests
For scenario 7:
GET /pki/keyrequests/recovery/approved --> get approved (but not yet completed) recovery requests
For scenario 3:
GET /pki/keys/clientID=foo;status=active
GET /pki/keys/clientID=foo;status=all
GET /pki/keys/clientID=foo;status=active;match=approx (return keys with approximate match for client ID)
There are also the standard ones already in the kra web pages (which we can easily expose too) - of which we mention
a couple above:
GET /pki/keyrequests/{type}/{state}
Anything I have missed?
Ade
12 years, 3 months
Request to build the following PKI components on Fedora 15, Fedora 16, and Fedora 17 (Rawhide) . . .
by Matthew Harmsen
Fixes have been made to address the following bugs:
* *Bugzilla Bug #747381*
<https://bugzilla.redhat.com/show_bug.cgi?id=747381> -After the
migration (7.1->8.1) CA agent page displays admin cert request with
authtime attribute twice
* *Bugzilla Bug #747019*
<https://bugzilla.redhat.com/show_bug.cgi?id=747019> -Migrated
policy requests from 7.1->8.1 displays issuedcerts and cert_Info
params as base 64 blobs.
* *Bugzilla Bug #757848*
<https://bugzilla.redhat.com/show_bug.cgi?id=757848> -DRM re-key
tool: introduces a blank line in the middle of an ldif entry.
* *Bugzilla Bug #756133*
<https://bugzilla.redhat.com/show_bug.cgi?id=756133> -Some DRM
components are not referring properly to DRM's request and key records.
* *Bugzilla Bug #758505*
<https://bugzilla.redhat.com/show_bug.cgi?id=758505> -DRM's request
list breaks after migration of request records with big IDs.
* *Bugzilla Bug #768138*
<https://bugzilla.redhat.com/show_bug.cgi?id=768138> -Make sure that
paging works correctly in CA and DRM
* *Bugzilla Bug #771357*
<https://bugzilla.redhat.com/show_bug.cgi?id=771357> -sslget does
not work after FEDORA-2011-17400 update, breaking FreeIPA install
Please build the following components on Fedora 15, Fedora 16, and
Fedora 17 (rawhide) in Koji . . .
* dogtag-pki-9.0.10-1.fc[15,16,17].src.rpm (dogtag-pki-theme)
* pki-core-9.0.17-1.fc[15,16,17].src.rpm (pki-core)
* dogtag-pki-9.0.0-9.fc[15,16,17].src.rpm (dogtag-pki)
All changes have been checked-in, and the official tarballs (for all
three platforms) have been published to:
* http://pki.fedoraproject.org/pki/sources/dogtag-pki-theme/dogtag-pki-them...
(dogtag-pki-theme)
* http://pki.fedoraproject.org/pki/sources/pki-core/pki-core-9.0.17.tar.gz
(pki-core)
The official spec files (for all three platforms) are located at:
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/dog...
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki...
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/dog...
Thanks,
-- Matt
12 years, 3 months