From alee at redhat.com Mon Jul 1 14:47:29 2013 From: alee at redhat.com (Ade Lee) Date: Mon, 01 Jul 2013 10:47:29 -0400 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <51CF4DDA.4080005@redhat.com> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> <1372430184.2327.35.camel@aleeredhat.laptop> <51CE6947.3020707@redhat.com> <1372533401.2327.45.camel@aleeredhat.laptop> <51CF4DDA.4080005@redhat.com> Message-ID: <1372690049.2304.10.camel@aleeredhat.laptop> On Sat, 2013-06-29 at 16:12 -0500, Endi Sukma Dewata wrote: > On 6/29/2013 2:16 PM, Ade Lee wrote: > > One thing I just noticed though is the operation to add a token. > > You have POST /tokens passing in the tokenId. > > > > POST /tokens is only used when creating a resource when the URL of the > > resource is unknown -- ie. it will be specified by the server. An > > example of this is POST /certrequests which returns the URL of the > > request /certrequests/0xf00 where 0xf00 is the request ID as assigned by > > the server. > > That is one way to use POST, but in general it doesn't always have to be > that limited. Consider the ID as an optional parameter. You can specify > it, but it's not specified the server could generate a new ID > automatically (not that we want to do that for this case). For the > client it would be easier to use the same operation to create a new > entry, with or without the ID. The operation that will work for both > cases is POST-ing into the collection. > > I don't think this is violating any REST guidelines. It's also > consistent with the add operation for the existing user and group resources. Maybe we need to revisit these then. > > > In this case, the token ID is what is being passed in. So we know the > > resultant URL when the resource is created. There are two options > > instead: > > > > a) PUT /tokens/tokenID > > b) POST /tokens/tokenID > > > > My preference is a) but of course the advantage of (b) is that there is > > a distinction between an ADD and a modify operation. > > > > The same comment applies to all the ADD operations in the design. > > The problem with (a) is that without ETag there's a risk overwriting an > existing token, and there's no warning or error message when that > happens. While ETag is desired, it should be optional (can we guarantee > all clients will support ETag?) and may not get implemented right away. > If we POST to the collection the server can reject it if the entry > already exists. Also, naturally an add operation is not idempotent, so > we should not use PUT. > The REST guidelines are precisely that - guidelines - and we can choose to ignore them at our discretion. But there are distinct advantages to following them. In particular, when doing so, anyone looking at the API knows exactly what is going on. By using PUT, its clear that the client is responsible for providing the resource ID. REST basically says to use the HTTP spec to determine what operation to use. To see what the REST guideline would be in this case, lets see what the HTTP spec says about PUT: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. The point you make about possibly overwriting an existing resource is valid -- but the answer there is etags. And as e will be writing the first clients for this, we can safely say that - yes - all clients will support etags. Just because we may not implement etags in the first iteration does not mean that we should use non-standard API in our design. > Option (b) is a little weird because usually we expect the resource > would already exist when we POST. POST-ing to the collection is fine > because the collection always exists. > I agree that option (b) is weird. From alee at redhat.com Mon Jul 1 16:37:05 2013 From: alee at redhat.com (Ade Lee) Date: Mon, 01 Jul 2013 12:37:05 -0400 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <51CE6947.3020707@redhat.com> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> <1372430184.2327.35.camel@aleeredhat.laptop> <51CE6947.3020707@redhat.com> Message-ID: <1372696625.2304.24.camel@aleeredhat.laptop> On Fri, 2013-06-28 at 23:57 -0500, Endi Sukma Dewata wrote: > On 6/28/2013 9:36 AM, Ade Lee wrote: > >>> Or is your intention to send in something with an "action" parameter - > >>> in which case, the correct operation is a POST? > >> > >> I use 'action' in the modify token operation because I couldn't find a > >> better replacement for the 'question' parameter in the original > >> op=do_token. Ideally it should be called 'status' but there's already > >> another attribute with that name. Any suggestion? This 'action' should > >> actually be returned by the GET operation too. I'll add it after we > >> finalize the name. > > > > do_token?question=X is essentially an operation where you are attempting > > to set the state of the token resource - for example, from "active" to > > "lost". There is no need for an additional parameter. > > I added a Change Token State operation: > http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Token_State > > As discussed, for now we'll call this parameter 'next state', which will > update the status & reason depending on the current state of the token. > > >>> 3. Should we be worried about a XSS attack here for modifying the state > >>> of the token? My guess is that we need to take advantage of the nonce > >>> mechanism, in which case, token state modification will require two > >>> steps. > >> > >> Yes, but similar to our discussion in the past, nonces or ETags can be > >> added in a later phase without changing the interface. Since the > >> modification is a PUT operation, and the request attributes are obtained > >> using a GET operation done earlier, this is a two-step operation. > >> Without the nonce or ETag the GET operation will be optional, and the > >> client can construct the request from scratch. But later the PUT > >> operation can require a nonce or ETag from a previous GET operation. > > > > OK, please put the nonce in the design. We dont want to forget it. > > I added two sections related to this: > http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Concurrency_Control > http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Vulnerabilities > > >>> 4. You should also note that we will be sending back BAD_REQUEST (401?) > >>> when the token state transition is not permitted. > >> > >> That should fall under "Normal application errors will return HTTP 4xx > >> return code." We can add more details as we implement it. > > > > Right, I'm just pointing this out because in this case, there is a state > > machine which determines which operations are successful. From the > > point of view of the API, doing a token transition is just an attempt to > > set the state of the token differently, but unlike something simple like > > just changing an attribute value, the operation is subject to the > > results of a state machine. > > I noted that in the response of Change Token State: > http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Token_State > > >>> 5. In the response to PUT /tokens/X, it is not necessary to return the > >>> state of the token. Rather, you should return a URL pointer to the > >>> newly modified resource. The same comment applies to the other PUT > >>> operations as well. > >> > >> Since PUT operation in general doesn't create a new resource, and also > >> the request is sent to the resource URL being modified, there is no need > >> to return a new location because it will be identical. In this design > >> the new location will only be returned on POST operations when adding a > >> new resource, which in this case the new resource location will be > >> different from the POST target (the resource collection). > >> > > Agreed. But in PUT /tokens/X, you return state information. This is > > not necessary. You should probably return nothing - other than status. > > See explanation in #10. > > >>> 6. Same question about XSS for add/remove token/ add/remove user. > >> > >> Similarly, nonces or ETags can be added later. As described earlier, > >> modifying users is a two-step process too with GET and PUT. Add and > >> remove operations do not require the client to do any other operation, > >> but it can be made so without changing the interface. The DELETE can > >> require a GET, but I'm not sure what operation should be required before > >> add. > >> > > Yeah - we need to think about ADD. Being able to add a privileged user > > for example by XSS would be troubling. > > I think we're mixing up CSRF and XSS. Nonces will be useful to prevent > CSRF. XSS can be prevented by encoding/escaping the values. > Thats correct. I was thinking about CSRF. > If we implement a single-page Web UI (like IPA Web UI) the client can > obtain a nonce during login, then the UI will keep the nonce in memory > throughout the session and use it for all update requests including add > (the nonce should really be called CSRF token). CSRF attack usually will > open a new page, so it will not be able to know the nonce. > > If we implement a multi-page Web UI (like the current Dogtag UI), the > add operation can be done in 2 steps. The first page will generate the > nonce, then the second page will execute the operation. > > >>> 9. Is there a mapping between Profile and Profile Mapping operations and > >>> the old operations? Please put that in so we can see whether we have > >>> complete coverage. In particular, I do not see an operation to > >>> approve/enable a profile. This is important because we have Common > >>> Criteria requirements that two users are involved in the approval of a > >>> profile. In our case, IIRC we implemented it such that an admin can > >>> configure a profile but an agent must approve it. > >> > >> There should be, but they are not in the docs and I have not had a > >> chance to test all possible operations in the UI. Once I get the TPS > >> instance back running I'll continue this. But in general we can > >> implement something similar to the cert requests: > >> > >> /tps/rest/profiles/{id}/approve (all approvers will use the same URL) > >> /tps/rest/profiles/{id}/enable > >> > > Thats fine - lets make sure we get those operations in. > > I added the missing mappings. I also added a Change Profile State operation: > http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Profile_State > The way this is written, it looks like you are just doing a POST to the /tps/rest/profiles/ and passing in "action" as a parameter. Thats not very RESTful at all. I think we want: /tps/rest/profiles/{id}/{action} where {action} is approve etc. This is also consistent with how we have done this for cert-requests etc. as well. > >>> 10. In POST /tps/rest/profilemappings, you return the location of the > >>> profile mappings as well as the contents of the profile mapping > >>> resource. You should just return the location. In fact, its probably > >>> better to just return locations in general. The client would then use > >>> GET to fetch the details if needed. This comment applies to many of the > >>> resources. > >> > >> In general I'd rather return the resource attributes in the POST > >> response than requiring the client to do a separate GET later. This > >> response acts as a receipt/acknowledgement for the add request, and it > >> will return the actual attributes stored on the server before any other > >> operation is done on it. This is rather important because sometimes a > >> lazy UI won't do an extra GET because it assumes the attributes don't > >> change, where in fact they could be normalized, ignored, or generated by > >> the server. It also prevents a possible (although unlikely) attack that > >> inserts an operation between the POST and GET. > > > > I guess you are suggesting the same for PUT requests as above. > > I'm not sure whether this is vaid reasoning or not. Just because you > > see what has been posted (or PUT) in the server does not mean that this > > data has not been changed the next time the data is accessed. > > There's never any guarantee that the data we get (either from PUT, POST, > or even GET) has not been changed when we submit it for another update > operation. The advantage of returning the data in PUT/POST response is > we're pushing the updated data to the client's feet. > > > If anything, returning this data encourages lazy clients. > > On the contrary, by returning the data in the PUT/POST response the > client will have little reason not to use it. If the client has no > intention to get the new data anyway (either from PUT/POST response or > by doing another GET) there's nothing we can do about it. But if the > client wants to get the new data, using PUT/POST response is a much > cheaper option. > > Compare the following code: > > user = users.update(user); > > with this: > > users.update(user); > user = users.get(user.getId()); > > > The fact is > > though that we will have to implement nonces and possibly etags, and so > > GETs will become mandatory for any changes. > > Not necessarily. ETag is only an optimistic lock; it's not a guarantee > that the data won't change. The PUT/POST response will also provide > ETag. Also see comment #6, we may be able to reuse the nonce. > > If there's nobody else updating the same data, we could reuse the > PUT/POST response and the ETag that came with it to make subsequent > update. So we're still using a two-step update process, but the 2nd step > of the first update may become the 1st step of the second update. See > also the Concurrency Control section in the wiki page. > > Imagine this, you updated a user, then you went to do some other > operations. Then you came back to this user and edited it again. If > there's nobody else changing the user, then the new data and ETag that > you got from the first update would still be valid. But if first update > happened a long time ago, the client may decide according to the caching > policy that the data has expired and then issue a GET to get a newer > data and ETag. > OK - I like the idea that the etag returned by the PUT/POST can be used for subsequent updates. We can go with this for now. > >>> 11. In the PUT /tps/rest/config, we have requirements for having than > >>> one user to approve changes. Admins make changes and agents approve > >>> them if I recall correctly. You should look at the differences between > >>> the agent and admin pages. > >> > >> I'll take a look again after I have the TPS instance back. Is there any > >> documents or diagrams showing the workflow of all approval processes in > >> TPS UI? Thanks. > >> > > The CC docs are probably the best bet for that (other than looking at > > the code). > > The only approval process I saw in the UI is for profiles, not for > general config. Could you point me to a specific page in the docs? > Yeah - I think thats right actually. All of the stuff thats in config did not require two agent approval. > Thanks. > From edewata at redhat.com Mon Jul 1 16:51:50 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 01 Jul 2013 11:51:50 -0500 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <1372690049.2304.10.camel@aleeredhat.laptop> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> <1372430184.2327.35.camel@aleeredhat.laptop> <51CE6947.3020707@redhat.com> <1372533401.2327.45.camel@aleeredhat.laptop> <51CF4DDA.4080005@redhat.com> <1372690049.2304.10.camel@aleeredhat.laptop> Message-ID: <51D1B3A6.8060505@redhat.com> On 7/1/2013 9:47 AM, Ade Lee wrote: > The REST guidelines are precisely that - guidelines - and we can choose > to ignore them at our discretion. But there are distinct advantages to > following them. In particular, when doing so, anyone looking at the API > knows exactly what is going on. By using PUT, its clear that the client > is responsible for providing the resource ID. > > REST basically says to use the HTTP spec to determine what operation to > use. To see what the REST guideline would be in this case, lets see > what the HTTP spec says about PUT: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 > > The PUT method requests that the enclosed entity be stored under the > supplied Request-URI. If the Request-URI refers to an already existing > resource, the enclosed entity SHOULD be considered as a modified version > of the one residing on the origin server. If the Request-URI does not > point to an existing resource, and that URI is capable of being defined > as a new resource by the requesting user agent, the origin server can > create the resource with that URI. If a new resource is created, the > origin server MUST inform the user agent via the 201 (Created) response. > If an existing resource is modified, either the 200 (OK) or 204 (No > Content) response codes SHOULD be sent to indicate successful completion > of the request. This defines what PUT does, but it doesn't necessarily require us to use PUT if we know the resource ID already. The POST is equally valid: From http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5: > The POST method is used to request that the origin server accept the > entity enclosed in the request as a new subordinate of the resource > identified by the Request-URI in the Request-Line. POST is designed > to allow a uniform method to cover the following functions: > > - Annotation of existing resources; > - Posting a message to a bulletin board, newsgroup, mailing list, > or similar group of articles; > - Providing a block of data, such as the result of submitting a > form, to a data-handling process; > - Extending a database through an append operation. > > The actual function performed by the POST method is determined by the > server and is usually dependent on the Request-URI. The posted entity > is subordinate to that URI in the same way that a file is subordinate > to a directory containing it, a news article is subordinate to a > newsgroup to which it is posted, or a record is subordinate to a > database. Adding a new user or profile into a collection would be analogous to the above examples. On 7/1/2013 9:47 AM, Ade Lee wrote: > The point you make about possibly overwriting an existing resource is > valid -- but the answer there is etags. And as e will be writing the > first clients for this, we can safely say that - yes - all clients will > support etags. With REST anybody can write their own client or use generic tools to access our interface. Of course the client must provide the required parameters in all requests, but if we require clients to use what supposed to be optional in REST we will reduce the number of clients that can use the interface. REST provides two different -- but valid -- mechanisms: PUT and POST. I think there are enough reasons to use separate operations for create and update: * Different behavior: create should fail if entry already exists where as update should fail if entry doesn't exist. * Different security: not all users are allowed to create an entry. * Server won't need to check if entry already exists. * If operation fails because entry exists/doesn't exist the client will know it. * Client won't need to determine which URL to use. * It works without ETag. Client won't need to do an extra GET operation. * Client can still use ETag if concurrency is a concern. Here's what Bill Burke said when we discussed about this when we're discussing the users interface: On 5/24/2012 11:33 AM, Bill Burke wrote: >> 1. Considering all the requirements, should CREATE and UPDATE be >> handled by a single or separate methods? > > Because you only want admins to be able to create a user, and non-admins > can update users, you should probably use the @Post method to create, > and not use @Put for creation. > > @POST @Path("/users") create(); > > for > > @PUT @Path("/users/{id}") update(); you should throw a 404 if the user > doesn't exist. >> Suppose the security requirements are the same for both operations, >> would you design it differently? > > All depends whether or not I wanted to rely on the client to pick the > URI or not. I usually use the @POST /users because it gives the server > a lot of flexibility on what the returned URI (in the Location header) > looks like. On 7/1/2013 9:47 AM, Ade Lee wrote: > Just because we may not implement etags in the first iteration does not > mean that we should use non-standard API in our design. Using POST won't be non-standard, but requiring ETag for this to work might be. Here's what Bill said: >> 3. Is it OK to require the use of ETag to distinguish CREATE and UPDATE >> (requiring a GET operation before every UPDATE)? Or should ETag be >> optional and used only if the system requires caching or concurrency >> control? > > It is never OK to override the meaning of a header, HTTP method, or > response code. One of the nice things about REST is that you have a > solid foundation of how a service behaves without ever looking at the > documentation of that service: This is because you know the HTTP protocol. > > ETag should only be used for conditional GET (when a cache is involved) > or a conditional PUT, or POST (When concurrency is involved). To me this means if someone installs a system and there's only one client using it, or any other situation where concurrency is not an issue, he shouldn't be required to use ETag. -- Endi S. Dewata From edewata at redhat.com Mon Jul 1 17:30:29 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 01 Jul 2013 12:30:29 -0500 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <51D1B3A6.8060505@redhat.com> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> <1372430184.2327.35.camel@aleeredhat.laptop> <51CE6947.3020707@redhat.com> <1372533401.2327.45.camel@aleeredhat.laptop> <51CF4DDA.4080005@redhat.com> <1372690049.2304.10.camel@aleeredhat.laptop> <51D1B3A6.8060505@redhat.com> Message-ID: <51D1BCB5.2090303@redhat.com> On 7/1/2013 11:51 AM, Endi Sukma Dewata wrote: > From http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5: >> The POST method is used to request that the origin server accept the >> entity enclosed in the request as a new subordinate of the resource >> identified by the Request-URI in the Request-Line. POST is designed >> to allow a uniform method to cover the following functions: >> >> - Annotation of existing resources; >> - Posting a message to a bulletin board, newsgroup, mailing list, >> or similar group of articles; >> - Providing a block of data, such as the result of submitting a >> form, to a data-handling process; >> - Extending a database through an append operation. >> >> The actual function performed by the POST method is determined by the >> server and is usually dependent on the Request-URI. The posted entity >> is subordinate to that URI in the same way that a file is subordinate >> to a directory containing it, a news article is subordinate to a >> newsgroup to which it is posted, or a record is subordinate to a >> database. > > Adding a new user or profile into a collection would be analogous to the > above examples. Just to clarify, when adding a file into a directory we know the file name already. Still, this is given as an example of a POST operation. So, knowing the ID ahead of time is irrelevant to picking PUT vs. POST to create a resource. -- Endi S. Dewata From edewata at redhat.com Mon Jul 1 18:12:17 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 01 Jul 2013 13:12:17 -0500 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <1372696625.2304.24.camel@aleeredhat.laptop> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> <1372430184.2327.35.camel@aleeredhat.laptop> <51CE6947.3020707@redhat.com> <1372696625.2304.24.camel@aleeredhat.laptop> Message-ID: <51D1C681.5010600@redhat.com> On 7/1/2013 11:37 AM, Ade Lee wrote: >> I also added a Change Profile State operation: >> http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Profile_State >> > The way this is written, it looks like you are just doing a POST to > the /tps/rest/profiles/ and passing in "action" as a > parameter. Thats not very RESTful at all. > > I think we want: > /tps/rest/profiles/{id}/{action} > > where {action} is approve etc. This is also consistent with how we have > done this for cert-requests etc. as well. This is where I'd like to see the current API changed. These actions (e.g. approve, enable) are not resources or collections. None of the other operations (GET, PUT, DELETE) make sense on actions. On the other hand, using POST to process data is a valid & RESTful operation. POST request should be sent to a resource, and the resource that we want to handle these actions is the target of the action (i.e. profile). According to POST definition: * The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. * The action performed by the POST method might not result in a resource that can be identified by a URI. * Example: - Providing a block of data, such as the result of submitting a form, to a data-handling process; According to http://www.ietf.org/rfc/rfc2616.txt (9.6 PUT): > The URI in a POST request identifies the resource that will handle > the enclosed entity. That resource might be a data-accepting process, > a gateway to some other protocol, or a separate entity that accepts > annotations. Also, POST-ing to /tps/rest/profiles/{id} will be more future-proof in case we add/remove actions later. -- Endi S. Dewata From akoneru at redhat.com Tue Jul 2 09:14:54 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 2 Jul 2013 05:14:54 -0400 (EDT) Subject: [Pki-devel] [PATCH] 62, 63, 64 Fixes to issues reported by pylint In-Reply-To: <28792628.13681990.1372756460809.JavaMail.root@redhat.com> Message-ID: <767273348.13682036.1372756494412.JavaMail.root@redhat.com> Please review the patches with fixes to errors reported by pylint in Dogtag 10. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0062-Fixes-for-issues-reported-by-pylint.patch Type: text/x-patch Size: 18348 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0063-Fixes-for-issues-reported-by-pylint.patch Type: text/x-patch Size: 9754 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0064-Fixes-for-issues-reported-by-pylint.patch Type: text/x-patch Size: 26030 bytes Desc: not available URL: From alee at redhat.com Tue Jul 2 13:44:46 2013 From: alee at redhat.com (Ade Lee) Date: Tue, 02 Jul 2013 09:44:46 -0400 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <51D1C681.5010600@redhat.com> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> <1372430184.2327.35.camel@aleeredhat.laptop> <51CE6947.3020707@redhat.com> <1372696625.2304.24.camel@aleeredhat.laptop> <51D1C681.5010600@redhat.com> Message-ID: <1372772686.2304.51.camel@aleeredhat.laptop> On Mon, 2013-07-01 at 13:12 -0500, Endi Sukma Dewata wrote: > On 7/1/2013 11:37 AM, Ade Lee wrote: > >> I also added a Change Profile State operation: > >> http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Profile_State > >> > > The way this is written, it looks like you are just doing a POST to > > the /tps/rest/profiles/ and passing in "action" as a > > parameter. Thats not very RESTful at all. > > > > I think we want: > > /tps/rest/profiles/{id}/{action} > > > > where {action} is approve etc. This is also consistent with how we have > > done this for cert-requests etc. as well. > > This is where I'd like to see the current API changed. These actions > (e.g. approve, enable) are not resources or collections. None of the > other operations (GET, PUT, DELETE) make sense on actions. > > On the other hand, using POST to process data is a valid & RESTful > operation. POST request should be sent to a resource, and the resource > that we want to handle these actions is the target of the action (i.e. > profile). > > According to POST definition: > * The actual function performed by the POST method is determined by the > server and is usually dependent on the Request-URI. > * The action performed by the POST method might not result in a resource > that can be identified by a URI. > * Example: > - Providing a block of data, such as the result of submitting a > form, to a data-handling process; > > According to http://www.ietf.org/rfc/rfc2616.txt (9.6 PUT): > > The URI in a POST request identifies the resource that will handle > > the enclosed entity. That resource might be a data-accepting process, > > a gateway to some other protocol, or a separate entity that accepts > > annotations. > Endi, the above definition is what has been referred to as overloaded-POST. Basically, its the way the whole RPC world uses the web. It would be entirely RESTful to create an interface using only POST - but wouldn't exactly be a Restful Oriented Architecture (ROA). Similarly one could create an entire interface using just GET and POST, entirely RESTful but not ROA. I looked back into my REST resources - in particular, Restful Web Services by Leonard Richardson and Sam Ruby, to find some standard practices/ advice to counter this approach. What I found was in fact the opposite. Let me quote Richardson: URIs are supposed to designate resources, not operations on the resources. This means it?s almost never appropriate to put the names of operations in your URIs. If you have a URI that looks like /object/do-operation, you?re in danger of slipping into the RPC style. Nobody wants to link to do-operation: they want to link to the object. Expose the operation through the uniform interface, or use overloaded POST if you have to, but make your URIs designate objects, not operations on the objects. So according to Richardson at least, its more RESTful to use overloaded POST and a query variable then to do what we have been doing. > Also, POST-ing to /tps/rest/profiles/{id} will be more future-proof in > case we add/remove actions later. Yes, this is a good point, although I can't shake the feeling that this makes the interface less intuitive and less discoverable. The actions we have exposed as for example, POST /certrequest/{id}/approve are basic operations that we currently expose and will want to expose in the future. POST /certrequest/{id} with action=approve seems more RPC-like in some way. Maybe its because the above mechanism really is RPC-like (because it uses overloaded POST) and using the action variable just makes that more apparent. Or maybe I need to shake the habit of creating URLs. If we decide to do this, we should consider changing the existing interfaces to follow this practice, before too many clients are written. Incidentally, there is a case where POST /foo/operation is acceptable and that is where you are in fact providing a processor to do an operation and are not generating resources. An example of this is in the TKS, where we request generation of a session key to communicate with a token. From alee at redhat.com Tue Jul 2 14:03:37 2013 From: alee at redhat.com (Ade Lee) Date: Tue, 02 Jul 2013 10:03:37 -0400 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <51D1BCB5.2090303@redhat.com> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> <1372430184.2327.35.camel@aleeredhat.laptop> <51CE6947.3020707@redhat.com> <1372533401.2327.45.camel@aleeredhat.laptop> <51CF4DDA.4080005@redhat.com> <1372690049.2304.10.camel@aleeredhat.laptop> <51D1B3A6.8060505@redhat.com> <51D1BCB5.2090303@redhat.com> Message-ID: <1372773817.2304.63.camel@aleeredhat.laptop> On Mon, 2013-07-01 at 12:30 -0500, Endi Sukma Dewata wrote: > On 7/1/2013 11:51 AM, Endi Sukma Dewata wrote: > > From http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5: > >> The POST method is used to request that the origin server accept the > >> entity enclosed in the request as a new subordinate of the resource > >> identified by the Request-URI in the Request-Line. POST is designed > >> to allow a uniform method to cover the following functions: > >> > >> - Annotation of existing resources; > >> - Posting a message to a bulletin board, newsgroup, mailing list, > >> or similar group of articles; > >> - Providing a block of data, such as the result of submitting a > >> form, to a data-handling process; > >> - Extending a database through an append operation. > >> > >> The actual function performed by the POST method is determined by the > >> server and is usually dependent on the Request-URI. The posted entity > >> is subordinate to that URI in the same way that a file is subordinate > >> to a directory containing it, a news article is subordinate to a > >> newsgroup to which it is posted, or a record is subordinate to a > >> database. > > > > Adding a new user or profile into a collection would be analogous to the > > above examples. > > Just to clarify, when adding a file into a directory we know the file > name already. Still, this is given as an example of a POST operation. > So, knowing the ID ahead of time is irrelevant to picking PUT vs. POST > to create a resource. > Just to be clear, it is perfectly RESTful to create an interface using only GET and POST. POST can literally be used for pretty much anything and still be restful. The question is more one of restful practice. Its far more intuitive and friendly to use the other verbs PUT and DELETE, even though there may be some clients that do not support these operations. As to this specific use of PUT vs. GET, I've seen best practice guidelines that advocate both scenarios. I am, however, most convinced by the idea that the POST allows the server more flexibility in selecting the Location. An example I saw of using PUT was for a user being able to store their personal set of favorites. For this case, it is entirely appropriate that the user controls the location URL. In our case, what we are creating are server resources and we want control over that. So, point conceded. From akoneru at redhat.com Tue Jul 2 15:23:06 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 02 Jul 2013 11:23:06 -0400 Subject: [Pki-devel] [PATCH] 62, 63, 64 Fixes to issues reported by pylint In-Reply-To: <767273348.13682036.1372756494412.JavaMail.root@redhat.com> References: <767273348.13682036.1372756494412.JavaMail.root@redhat.com> Message-ID: <1372778586.975.1.camel@akoneru.redhat.com> Fixed the trailing whitespace errors in all patches and removed the unused variables in pkiparser.py as mentioned by Ade on IRC. Pushed all three patches to master. --Abhishek On Tue, 2013-07-02 at 05:14 -0400, Abhishek Koneru wrote: > Please review the patches with fixes to errors reported by pylint in Dogtag 10. > > --Abhishek > _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Tue Jul 2 19:54:05 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 02 Jul 2013 14:54:05 -0500 Subject: [Pki-devel] [PATCH] 264 Added support to backup folders during upgrade. In-Reply-To: <51ACC670.5010202@redhat.com> References: <51ACC670.5010202@redhat.com> Message-ID: <51D32FDD.3020701@redhat.com> On 6/3/2013 11:38 AM, Endi Sukma Dewata wrote: > The upgrade framework has been updated to support backup and restore > operations for folders and their contents. > > Ticket #583 New patch attached. Fixed a small bug and rebased against master. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0264-1-Added-support-to-backup-folders-during-upgrade.patch Type: text/x-patch Size: 13689 bytes Desc: not available URL: From akoneru at redhat.com Wed Jul 3 17:55:15 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 3 Jul 2013 13:55:15 -0400 (EDT) Subject: [Pki-devel] [PATCH] 65 Some more fixes for issues reported by pylint #316 In-Reply-To: <519598135.14187145.1372874111159.JavaMail.root@redhat.com> Message-ID: <461741106.14187164.1372874115047.JavaMail.root@redhat.com> Please review the attached patch with some more fixes for issues reported by pylint in dogtag 10. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0065-Fixes-for-issues-reported-by-pylint.patch Type: text/x-patch Size: 13227 bytes Desc: not available URL: From akoneru at redhat.com Wed Jul 3 19:46:19 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 3 Jul 2013 15:46:19 -0400 (EDT) Subject: [Pki-devel] [PATCH] 65 Some more fixes for issues reported by pylint #316 In-Reply-To: <461741106.14187164.1372874115047.JavaMail.root@redhat.com> References: <461741106.14187164.1372874115047.JavaMail.root@redhat.com> Message-ID: <1587862347.14213679.1372880779606.JavaMail.root@redhat.com> ACK'ed by Ade on irc. Pushed to master. --Abhishek ----- Original Message ----- From: "Abhishek Koneru" To: pki-devel at redhat.com Sent: Wednesday, July 3, 2013 1:55:15 PM Subject: [Pki-devel] [PATCH] 65 Some more fixes for issues reported by pylint #316 Please review the attached patch with some more fixes for issues reported by pylint in dogtag 10. --Abhishek _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Sat Jul 6 04:17:10 2013 From: alee at redhat.com (Ade Lee) Date: Sat, 06 Jul 2013 00:17:10 -0400 Subject: [Pki-devel] [PATCH] 264 Added support to backup folders during upgrade. In-Reply-To: <51D32FDD.3020701@redhat.com> References: <51ACC670.5010202@redhat.com> <51D32FDD.3020701@redhat.com> Message-ID: <1373084230.3388.0.camel@localhost.localdomain> ACK On Tue, 2013-07-02 at 14:54 -0500, Endi Sukma Dewata wrote: > On 6/3/2013 11:38 AM, Endi Sukma Dewata wrote: > > The upgrade framework has been updated to support backup and restore > > operations for folders and their contents. > > > > Ticket #583 > > New patch attached. Fixed a small bug and rebased against master. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Mon Jul 8 19:04:28 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 08 Jul 2013 14:04:28 -0500 Subject: [Pki-devel] [PATCH] 264 Added support to backup folders during upgrade. In-Reply-To: <1373084230.3388.0.camel@localhost.localdomain> References: <51ACC670.5010202@redhat.com> <51D32FDD.3020701@redhat.com> <1373084230.3388.0.camel@localhost.localdomain> Message-ID: <51DB0D3C.4000405@redhat.com> On 7/5/2013 11:17 PM, Ade Lee wrote: > ACK Pushed to master. -- Endi S. Dewata From akoneru at redhat.com Tue Jul 9 16:27:11 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 09 Jul 2013 12:27:11 -0400 Subject: [Pki-devel] [PATCH] 66, 67 Fixing warnings reported by pylint in Dogtag 10 python code. Message-ID: <1373387231.6557.4.camel@akoneru.redhat.com> Please review the patches which address the following warnings reported by pylint. +-----------+------------+ |message id |occurrences | +===========+============+ |W0403 |84 |Relative import error (Need to investigate.) +-----------+------------+ |W1401 |34 |Anomalous backslash in string: ?%s?. (All occurences in regex patterns) +-----------+------------+ |W0613 |12 |Unused argument %r (This is mainly due to the keyboard interrupt handler - in every script ) +-----------+------------+ |W0221 |6 |Arguments number differs from %s method (These cases are basic function overriding, did not find a specific reason as to why this is causing a warning) +-----------+------------+ |W0621 |4 |Redefining name %r from outer scope (All cases related to interrupt handler code in pki* scripts) +-----------+------------+ |W0212 |4 |Access to a protected member %s of a client class (Found in pkiparser.py in compose_slots_dict function. This is the only way for retrieving all the key-value pairs in a section ) +-----------+------------+ (without any entries from the default sections in the dict.) |W0612 |1 |Unused variable %r (A starightforward fix) +-----------+------------+ Issues remaining to be fixed - Messages -------- +-----------+------------+ |message id |occurrences | +===========+============+ |W0201 |25 |Attribute %r defined outside __init__ +-----------+------------+ |E0202 |1 |An attribute affected in %s line %s hide this method. E0202: 15,4:CustomTypeEncoder.default: An attribute affected in json.encoder line 157 hide this method (in encoder.py) +-----------+------------+ --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0067-Fixes-for-issues-reported-by-pylint.patch Type: text/x-patch Size: 10527 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0066-Fix-issues-reported-by-pylint.patch Type: text/x-patch Size: 13321 bytes Desc: not available URL: From akoneru at redhat.com Tue Jul 9 18:19:41 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 09 Jul 2013 14:19:41 -0400 Subject: [Pki-devel] [PATCH] 66, 67 Fixing warnings reported by pylint in Dogtag 10 python code. In-Reply-To: <1373387231.6557.4.camel@akoneru.redhat.com> References: <1373387231.6557.4.camel@akoneru.redhat.com> Message-ID: <1373393981.6557.6.camel@akoneru.redhat.com> Sorry for the spam. The comments mentioned were from the report before. --Abhishek On Tue, 2013-07-09 at 12:27 -0400, Abhishek Koneru wrote: > Please review the patches which address the following warnings reported > by pylint. > > +-----------+------------+ > |message id |occurrences | > +===========+============+ > |W0403 |84 |Relative import error (Need to investigate.) > +-----------+------------+ > |W1401 |34 |Anomalous backslash in string: ?%s?. (All > occurences in regex patterns) > +-----------+------------+ > |W0613 |12 |Unused argument %r (This is mainly due to the > keyboard interrupt handler - in every script ) > +-----------+------------+ > |W0221 |6 |Arguments number differs from %s method (These > cases are basic function overriding, did not find a specific reason as > to why this is causing a warning) > +-----------+------------+ > |W0621 |4 |Redefining name %r from outer scope (All cases > related to interrupt handler code in pki* scripts) > +-----------+------------+ > |W0212 |4 |Access to a protected member %s of a client > class (Found in pkiparser.py in compose_slots_dict function. This is the > only way for retrieving all the key-value pairs in a section ) > +-----------+------------+ (without any entries from the default > sections in the dict.) > |W0612 |1 |Unused variable %r (A starightforward fix) > +-----------+------------+ > > > Issues remaining to be fixed - > > Messages > -------- > > +-----------+------------+ > |message id |occurrences | > +===========+============+ > |W0201 |25 |Attribute %r defined outside __init__ > +-----------+------------+ > |E0202 |1 |An attribute affected in %s line %s hide this > method. E0202: 15,4:CustomTypeEncoder.default: An attribute affected in > json.encoder line 157 hide this method (in encoder.py) > +-----------+------------+ > > --Abhishek > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Wed Jul 10 15:30:00 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 10 Jul 2013 10:30:00 -0500 Subject: [Pki-devel] [PATCH] 270 Moved script to remove JNI_JAR_DIR to 10.0.3 folder. Message-ID: <51DD7DF8.5070008@redhat.com> The redundant JNI_JAR_DIR will be removed from /etc/pki/pki.conf starting from version 10.0.4. Empty folders need be created for each released version number to allow proper upgrade and revert operations. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0270-Moved-script-to-remove-JNI_JAR_DIR-to-10.0.3-folder.patch Type: text/x-patch Size: 1813 bytes Desc: not available URL: From edewata at redhat.com Wed Jul 10 15:30:33 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 10 Jul 2013 10:30:33 -0500 Subject: [Pki-devel] [PATCH] 271 Added man pages for upgrade tools. Message-ID: <51DD7E19.9070401@redhat.com> New man pages have been added for pki-upgrade and pki-server-upgrade. The spec file and build scripts have been updated accordingly. Ticket #582 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0271-Added-man-pages-for-upgrade-tools.patch Type: text/x-patch Size: 20587 bytes Desc: not available URL: From edewata at redhat.com Wed Jul 10 17:41:49 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 10 Jul 2013 12:41:49 -0500 Subject: [Pki-devel] [PATCH] 270 Moved script to remove JNI_JAR_DIR to 10.0.3 folder. In-Reply-To: <51DD7DF8.5070008@redhat.com> References: <51DD7DF8.5070008@redhat.com> Message-ID: <51DD9CDD.4070702@redhat.com> On 7/10/2013 10:30 AM, Endi Sukma Dewata wrote: > The redundant JNI_JAR_DIR will be removed from /etc/pki/pki.conf > starting from version 10.0.4. > > Empty folders need be created for each released version number to allow > proper upgrade and revert operations. > ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Wed Jul 10 17:44:31 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 10 Jul 2013 12:44:31 -0500 Subject: [Pki-devel] [PATCH] 250 Added support for backup/restore on upgrade. In-Reply-To: <5193E760.4010408@redhat.com> References: <518BBEAD.8080300@redhat.com> <5193E760.4010408@redhat.com> Message-ID: <51DD9D7F.80008@redhat.com> On 5/15/2013 2:52 PM, Endi Sukma Dewata wrote: > ACKed by Ade. > > Renamed the backup file/folders into 'newfiles' & 'oldfiles'. Pushed to > master. > > The followings will be done in additional patches: > 1. Support for reverting individual instances/subsystems. > 2. Support for backing up folders including the ownerships, permissions, > and contents. > Pushed to 10.0.x branch. -- Endi S. Dewata From edewata at redhat.com Wed Jul 10 17:44:41 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 10 Jul 2013 12:44:41 -0500 Subject: [Pki-devel] [PATCH] 251 Removing JNI_JAR_DIR from /etc/pki/pki.conf. In-Reply-To: <5193E781.2020606@redhat.com> References: <518BC04C.1020200@redhat.com> <5193E781.2020606@redhat.com> Message-ID: <51DD9D89.3060303@redhat.com> On 5/15/2013 2:52 PM, Endi Sukma Dewata wrote: > ACKed by Ade. Pushed to master. > Pushed to 10.0.x branch. -- Endi S. Dewata From edewata at redhat.com Wed Jul 10 17:44:55 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 10 Jul 2013 12:44:55 -0500 Subject: [Pki-devel] [PATCH] 264 Added support to backup folders during upgrade. In-Reply-To: <51DB0D3C.4000405@redhat.com> References: <51ACC670.5010202@redhat.com> <51D32FDD.3020701@redhat.com> <1373084230.3388.0.camel@localhost.localdomain> <51DB0D3C.4000405@redhat.com> Message-ID: <51DD9D97.2080902@redhat.com> On 7/8/2013 2:04 PM, Endi Sukma Dewata wrote: > On 7/5/2013 11:17 PM, Ade Lee wrote: >> ACK > > Pushed to master. > Pushed to 10.0.x branch. -- Endi S. Dewata From akoneru at redhat.com Wed Jul 10 18:14:28 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 10 Jul 2013 14:14:28 -0400 Subject: [Pki-devel] [PATCH] 66, 67 Fixing warnings reported by pylint in Dogtag 10 python code. In-Reply-To: <1373393981.6557.6.camel@akoneru.redhat.com> References: <1373387231.6557.4.camel@akoneru.redhat.com> <1373393981.6557.6.camel@akoneru.redhat.com> Message-ID: <1373480068.19839.1.camel@akoneru.redhat.com> Fixed the trailing whitespace errors and enabled the pylint check for W0212 - Accessing protected variables on discussing with Ade. The fixed patches are pushed to master. --Abhishek On Tue, 2013-07-09 at 14:19 -0400, Abhishek Koneru wrote: > Sorry for the spam. The comments mentioned were from the report before. > --Abhishek > On Tue, 2013-07-09 at 12:27 -0400, Abhishek Koneru wrote: > > Please review the patches which address the following warnings reported > > by pylint. > > > > +-----------+------------+ > > |message id |occurrences | > > +===========+============+ > > |W0403 |84 |Relative import error (Need to investigate.) > > +-----------+------------+ > > |W1401 |34 |Anomalous backslash in string: ?%s?. (All > > occurences in regex patterns) > > +-----------+------------+ > > |W0613 |12 |Unused argument %r (This is mainly due to the > > keyboard interrupt handler - in every script ) > > +-----------+------------+ > > |W0221 |6 |Arguments number differs from %s method (These > > cases are basic function overriding, did not find a specific reason as > > to why this is causing a warning) > > +-----------+------------+ > > |W0621 |4 |Redefining name %r from outer scope (All cases > > related to interrupt handler code in pki* scripts) > > +-----------+------------+ > > |W0212 |4 |Access to a protected member %s of a client > > class (Found in pkiparser.py in compose_slots_dict function. This is the > > only way for retrieving all the key-value pairs in a section ) > > +-----------+------------+ (without any entries from the default > > sections in the dict.) > > |W0612 |1 |Unused variable %r (A starightforward fix) > > +-----------+------------+ > > > > > > Issues remaining to be fixed - > > > > Messages > > -------- > > > > +-----------+------------+ > > |message id |occurrences | > > +===========+============+ > > |W0201 |25 |Attribute %r defined outside __init__ > > +-----------+------------+ > > |E0202 |1 |An attribute affected in %s line %s hide this > > method. E0202: 15,4:CustomTypeEncoder.default: An attribute affected in > > json.encoder line 157 hide this method (in encoder.py) > > +-----------+------------+ > > > > --Abhishek > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From akoneru at redhat.com Wed Jul 10 18:19:32 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 10 Jul 2013 14:19:32 -0400 Subject: [Pki-devel] [PATCH] 68 Fix for a bug raised due to a fix for pylint warning in upgrade scripts Message-ID: <1373480372.19839.4.camel@akoneru.redhat.com> Please review a fix for a bug found in code due to a fix in one of the patches fixing the pylint issues. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0068-Fix-a-bug-raised-in-upgrade-scripts.patch Type: text/x-patch Size: 1803 bytes Desc: not available URL: From alee at redhat.com Wed Jul 10 20:25:04 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 10 Jul 2013 16:25:04 -0400 Subject: [Pki-devel] [PATCH] cloning issues in 8.1 Message-ID: <1373487904.1527.6.camel@aleeredhat.laptop> This is in response to Basically, there are two issues. 1. We want to use the selected CA to generate the SSL server cert. In the code though, for a clone, the code that sets the relevant preop parameter used to determine the right CA to go to - is only run after we issue the sslserver cert request. That means it always goes to the security domain CA. This code is now reversed. 2. Due to a DS bug (which has been fixed), the attributes on the pkiSubsystem entry in the clone CA security domain database we in lower case, rather than the existing case. Thats actually ok from an ldap point of view. We create some XML from those attributes -- just in case, we should make the XML matches in this case case insensitive. Please review. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: cloning.patch Type: text/x-patch Size: 20851 bytes Desc: not available URL: From alee at redhat.com Wed Jul 10 20:26:08 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 10 Jul 2013 16:26:08 -0400 Subject: [Pki-devel] [PATCH] cloning issues in 8.1 In-Reply-To: <1373487904.1527.6.camel@aleeredhat.laptop> References: <1373487904.1527.6.camel@aleeredhat.laptop> Message-ID: <1373487968.1527.7.camel@aleeredhat.laptop> Opps - bug this time too: https://bugzilla.redhat.com/show_bug.cgi?id=982320 On Wed, 2013-07-10 at 16:25 -0400, Ade Lee wrote: > This is in response to > > Basically, there are two issues. > > 1. We want to use the selected CA to generate the SSL server cert. In > the code though, for a clone, the code that sets the relevant preop > parameter used to determine the right CA to go to - is only run after we > issue the sslserver cert request. That means it always goes to the > security domain CA. This code is now reversed. > > 2. Due to a DS bug (which has been fixed), the attributes on the > pkiSubsystem entry in the clone CA security domain database we in lower > case, rather than the existing case. Thats actually ok from an ldap > point of view. We create some XML from those attributes -- just in > case, we should make the XML matches in this case case insensitive. > > Please review. > > Thanks, > Ade > From edewata at redhat.com Wed Jul 10 21:38:39 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 10 Jul 2013 16:38:39 -0500 Subject: [Pki-devel] [PATCH] 272 Reorganized server files. Message-ID: <51DDD45F.4030704@redhat.com> Some server files in base/common have been moved to base/server for consistency. The build scripts have been updated accordingly. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0272-Reorganized-server-files.patch Type: text/x-patch Size: 27441 bytes Desc: not available URL: From edewata at redhat.com Sat Jul 13 16:23:51 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 13 Jul 2013 11:23:51 -0500 Subject: [Pki-devel] [PATCH] 272 Reorganized server files. In-Reply-To: <51DDD45F.4030704@redhat.com> References: <51DDD45F.4030704@redhat.com> Message-ID: <51E17F17.8080904@redhat.com> On 7/10/2013 4:38 PM, Endi Sukma Dewata wrote: > Some server files in base/common have been moved to base/server for > consistency. The build scripts have been updated accordingly. ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Jul 16 21:45:56 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 16 Jul 2013 16:45:56 -0500 Subject: [Pki-devel] [PATCH] 273 Added option to override compose work directory. Message-ID: <51E5BF14.5010607@redhat.com> Currently the compose scripts always use a fixed work directory called "packages" to do the build. To provide more flexibility, a new optional parameter has been added to allow overriding the work directory. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0273-Added-option-to-override-compose-work-directory.patch Type: text/x-patch Size: 6521 bytes Desc: not available URL: From akoneru at redhat.com Tue Jul 16 21:59:08 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 16 Jul 2013 17:59:08 -0400 Subject: [Pki-devel] [PATCH] 68 - 2 Fix for a bug raised due to a fix for pylint warning in upgrade scripts In-Reply-To: <1373480372.19839.4.camel@akoneru.redhat.com> References: <1373480372.19839.4.camel@akoneru.redhat.com> Message-ID: <1374011948.2158.3.camel@akoneru.redhat.com> On discussion with Endi on IRC, the variable name is changed from vtype to instanceType. (the actual warning was using built-in name 'type' for a variable, which was changed to vtype, which is now changed to instanceType). That change was also made to the instance attribute of PKIInstance, which is now reverted back to type. Please review the patch and acknowledge for being able to push it to master. --Abhishek On Wed, 2013-07-10 at 14:19 -0400, Abhishek Koneru wrote: > Please review a fix for a bug found in code due to a fix in one of the > patches fixing the pylint issues. > > --Abhishek > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0068-2-Fix-a-defect-in-upgrade-scripts.patch Type: text/x-patch Size: 1446 bytes Desc: not available URL: From edewata at redhat.com Tue Jul 16 22:16:38 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 16 Jul 2013 17:16:38 -0500 Subject: [Pki-devel] [PATCH] 274 Reorganized deployment tools. Message-ID: <51E5C646.20307@redhat.com> The pkispawn and pkidestroy scripts have been moved into sbin folder. The Python deployment library and the scriptlets were moved into pki.server.deployment and pki.server.deployment.scriptlets packages, respectively. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0274-Reorganized-deployment-tools.patch Type: text/x-patch Size: 20576 bytes Desc: not available URL: From edewata at redhat.com Tue Jul 16 22:25:14 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 16 Jul 2013 17:25:14 -0500 Subject: [Pki-devel] [PATCH] 68 - 2 Fix for a bug raised due to a fix for pylint warning in upgrade scripts In-Reply-To: <1374011948.2158.3.camel@akoneru.redhat.com> References: <1373480372.19839.4.camel@akoneru.redhat.com> <1374011948.2158.3.camel@akoneru.redhat.com> Message-ID: <51E5C84A.9090304@redhat.com> On 7/16/2013 4:59 PM, Abhishek Koneru wrote: > On discussion with Endi on IRC, the variable name is changed from vtype > to instanceType. (the actual warning was using built-in name 'type' for > a variable, which was changed to vtype, which is now changed to > instanceType). That change was also made to the instance attribute of > PKIInstance, which is now reverted back to type. > > Please review the patch and acknowledge for being able to push it to > master. ACK. -- Endi S. Dewata From edewata at redhat.com Tue Jul 16 22:37:36 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 16 Jul 2013 17:37:36 -0500 Subject: [Pki-devel] [PATCH] 274 Reorganized deployment tools. In-Reply-To: <51E5C646.20307@redhat.com> References: <51E5C646.20307@redhat.com> Message-ID: <51E5CB30.50709@redhat.com> On 7/16/2013 5:16 PM, Endi Sukma Dewata wrote: > The pkispawn and pkidestroy scripts have been moved into sbin folder. > The Python deployment library and the scriptlets were moved into > pki.server.deployment and pki.server.deployment.scriptlets packages, > respectively. Clarification, the installation location of pkispawn & pkidestroy doesn't change, it has always been /usr/sbin. I'm only moving their location in the source tree from base/server/src into base/server/sbin to match the actual installation location. I'll fix the commit log. -- Endi S. Dewata From edewata at redhat.com Wed Jul 17 16:37:13 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 17 Jul 2013 11:37:13 -0500 Subject: [Pki-devel] [PATCH] 275 Fixed token authentication problem on RHEL. Message-ID: <51E6C839.7040605@redhat.com> The CryptoManager.initialize() and CryptoToken.login() invocation has been moved into the main program as a workaround for the authentication problem on RHEL and to ensure proper initialization in general. Bugzilla #985111 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0275-Fixed-token-authentication-problem-on-RHEL.patch Type: text/x-patch Size: 10330 bytes Desc: not available URL: From edewata at redhat.com Wed Jul 17 17:11:28 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 17 Jul 2013 12:11:28 -0500 Subject: [Pki-devel] [PATCH] 276 Cleaned up code to install man pages. Message-ID: <51E6D040.2050808@redhat.com> The code to install man pages in the spec file and CMake scripts has been cleaned up for clarity. Ticket #582 Note: Patch #271 will need to be rebased. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0276-Cleaned-up-code-to-install-man-pages.patch Type: text/x-patch Size: 3523 bytes Desc: not available URL: From akoneru at redhat.com Wed Jul 17 20:38:02 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 17 Jul 2013 16:38:02 -0400 Subject: [Pki-devel] [PATCH] 69 Last set of fixes for warnings and errors reported by pylint for Dogtag10.1 branch Message-ID: <1374093482.1407.4.camel@akoneru.redhat.com> Please review the patch with fixes for remaining two issues reported by pylint. 1. Attribute defined outside init. 2. Instance attribute hiding a class method (Ignored as the problem is in json.encoder.JSONEncoder). Also attached the final report. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0069-Fixes-for-issues-reported-by-pylint.patch Type: text/x-patch Size: 4955 bytes Desc: not available URL: -------------- next part -------------- Report ====== 8030 statements analysed. External dependencies --------------------- :: ldap (pki.deployment.pkiparser,pkispawn) pki (pki-upgrade,pki.upgrade,pki.deployment.pkiparser,pki.server,pki/server/,pki-server-upgrade,pki.server.upgrade) \-account (pki.deployment.pkiparser,pki.deployment.pkihelper) \-client (pki.deployment.pkiparser,pki.deployment.pkihelper) \-deployment | \-pkiconfig (pki.deployment.pkihelper,pki.deployment.webapp_deployment,pki.deployment.pkimanifest,pki.deployment.pkiparser,pkidestroy,pki.deployment.initialization,pki.deployment.selinux_setup,pki.deployment.instance_layout,pki.deployment.security_databases,pkispawn,pki.deployment.infrastructure_layout,pki.deployment.finalization,pki.deployment.configuration,pki.deployment.slot_substitution,pki.deployment.subsystem_layout) | | \-pki_selinux_config_ports (pki.deployment.pkihelper,pki.deployment.selinux_setup) | \-pkihelper (pkidestroy,pkispawn) | \-pkilogging (pki.deployment.pkiparser,pkidestroy,pkispawn) | \-pkimanifest (pki.deployment.pkihelper,pki.deployment.finalization) | \-pkimessages (pki.deployment.pkihelper,pki.deployment.webapp_deployment,pki.deployment.pkimanifest,pki.deployment.pkiparser,pkidestroy,pki.deployment.initialization,pki.deployment.selinux_setup,pki.deployment.instance_layout,pki.deployment.security_databases,pkispawn,pki.deployment.infrastructure_layout,pki.deployment.finalization,pki.deployment.configuration,pki.deployment.slot_substitution,pki.deployment.subsystem_layout) | \-pkiparser | | \-PKIConfigParser (pki.deployment.pkihelper,pkidestroy,pkispawn) | \-pkiscriptlet (pki.deployment.webapp_deployment,pki.deployment.finalization,pki.deployment.initialization,pki.deployment.selinux_setup,pki.deployment.instance_layout,pki.deployment.security_databases,pki.deployment.infrastructure_layout,pki.deployment.configuration,pki.deployment.slot_substitution,pki.deployment.subsystem_layout) \-encoder (pki.system,pki.deployment.configuration) \-server (pki.server.upgrade) | \-upgrade (pki-server-upgrade) \-system (pki.deployment.pkiparser,pki.deployment.pkihelper,pki.deployment.configuration) \-upgrade (pki.deployment.pkiparser,pki-server-upgrade,pki.server.upgrade,pki-upgrade) | \-verbose (pki.server.upgrade) \-util (pki.upgrade) requests (pki.deployment.pkiparser,pki.client,pkispawn,pki.deployment.pkihelper) selinux (pki.deployment.pkihelper,pki.deployment.selinux_setup) seobject (pki.deployment.pkihelper,pki.deployment.selinux_setup) Statistics by type ------------------ +---------+-------+-----------+-----------+------------+---------+ |type |number |old number |difference |%documented |%badname | +=========+=======+===========+===========+============+=========+ |module |51 |51 |= |NC |NC | +---------+-------+-----------+-----------+------------+---------+ |class |86 |86 |= |NC |NC | +---------+-------+-----------+-----------+------------+---------+ |method |407 |407 |= |NC |NC | +---------+-------+-----------+-----------+------------+---------+ |function |32 |32 |= |NC |NC | +---------+-------+-----------+-----------+------------+---------+ Messages by category -------------------- +-----------+-------+---------+-----------+ |type |number |previous |difference | +===========+=======+=========+===========+ |convention |0 |0 |= | +-----------+-------+---------+-----------+ |refactor |0 |0 |= | +-----------+-------+---------+-----------+ |warning |0 |0 |= | +-----------+-------+---------+-----------+ |error |0 |1 |-1.00 | +-----------+-------+---------+-----------+ Global evaluation ----------------- Your code has been rated at 10.00/10 (previous run: 9.99/10) Duplication ----------- +-------------------------+-------+---------+-----------+ | |now |previous |difference | +=========================+=======+=========+===========+ |nb duplicated lines |7564 |7564 |= | +-------------------------+-------+---------+-----------+ |percent duplicated lines |45.687 |45.687 |= | +-------------------------+-------+---------+-----------+ Raw metrics ----------- +----------+-------+------+---------+-----------+ |type |number |% |previous |difference | +==========+=======+======+=========+===========+ |code |11088 |73.76 |11088 |= | +----------+-------+------+---------+-----------+ |docstring |990 |6.59 |990 |= | +----------+-------+------+---------+-----------+ |comment |1920 |12.77 |1919 |+1.00 | +----------+-------+------+---------+-----------+ |empty |1034 |6.88 |1035 |-1.00 | +----------+-------+------+---------+-----------+ From edewata at redhat.com Wed Jul 17 21:19:16 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 17 Jul 2013 16:19:16 -0500 Subject: [Pki-devel] [PATCH] 277 Fixed dependency issue on CMSRequest. Message-ID: <51E70A54.2090802@redhat.com> The CMSRequest is a server class but it's used by the ICommandQueue that belongs in the base package. To fix the dependency issue the CMSRequest has been refactored to implement a new interface ICMSRequest in the base package. Some constants in CMSRequest have also been moved into ICMSRequest. All code referencing CMSRequest has been adjusted accordingly. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0277-Fixed-dependency-issue-on-CMSRequest.patch Type: text/x-patch Size: 179178 bytes Desc: not available URL: From akoneru at redhat.com Wed Jul 17 21:25:36 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 17 Jul 2013 17:25:36 -0400 Subject: [Pki-devel] [PATCH] 70 Small changes to Installation summary for 10.0 branch#645 Message-ID: <1374096336.1407.7.camel@akoneru.redhat.com> Please review the patch which adds the client dir to the installation summary and some formatting. Also should this patch be pushed to master? --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0070-Minor-changes-in-Installation-Summary.patch Type: text/x-patch Size: 3212 bytes Desc: not available URL: From alee at redhat.com Thu Jul 18 14:47:15 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 18 Jul 2013 10:47:15 -0400 Subject: [Pki-devel] [PATCH] 69 Last set of fixes for warnings and errors reported by pylint for Dogtag10.1 branch In-Reply-To: <1374093482.1407.4.camel@akoneru.redhat.com> References: <1374093482.1407.4.camel@akoneru.redhat.com> Message-ID: <1374158835.2236.1.camel@localhost.localdomain> ACK Extraneous E202 in comment in encoder class. As discussed, please add more description of the E202 problem in encoder.pl so we know why we are ignoring it. Ade On Wed, 2013-07-17 at 16:38 -0400, Abhishek Koneru wrote: > Please review the patch with fixes for remaining two issues reported by > pylint. > > 1. Attribute defined outside init. > 2. Instance attribute hiding a class method (Ignored as the problem is > in json.encoder.JSONEncoder). > > Also attached the final report. > > --Abhishek > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From akoneru at redhat.com Thu Jul 18 15:41:52 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 18 Jul 2013 11:41:52 -0400 Subject: [Pki-devel] [PATCH] 69 Last set of fixes for warnings and errors reported by pylint for Dogtag10.1 branch In-Reply-To: <1374158835.2236.1.camel@localhost.localdomain> References: <1374093482.1407.4.camel@akoneru.redhat.com> <1374158835.2236.1.camel@localhost.localdomain> Message-ID: <1374162112.1188.1.camel@akoneru.redhat.com> Added the description and removed the extraneous E0202 in the comment. Pushed to master. -Abhishek On Thu, 2013-07-18 at 10:47 -0400, Ade Lee wrote: > ACK > > Extraneous E202 in comment in encoder class. > As discussed, please add more description of the E202 problem in > encoder.pl so we know why we are ignoring it. > > Ade > > On Wed, 2013-07-17 at 16:38 -0400, Abhishek Koneru wrote: > > Please review the patch with fixes for remaining two issues reported by > > pylint. > > > > 1. Attribute defined outside init. > > 2. Instance attribute hiding a class method (Ignored as the problem is > > in json.encoder.JSONEncoder). > > > > Also attached the final report. > > > > --Abhishek > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > From akoneru at redhat.com Thu Jul 18 20:42:10 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 18 Jul 2013 16:42:10 -0400 (EDT) Subject: [Pki-devel] [PATCH] 70 Small changes to Installation summary for 10.0 branch#645 In-Reply-To: <1374096336.1407.7.camel@akoneru.redhat.com> References: <1374096336.1407.7.camel@akoneru.redhat.com> Message-ID: <1567761479.1395087.1374180130797.JavaMail.root@redhat.com> The following was agreed to be part of the installation summary after discussions on IRC. ========================================================================== INSTALLATION SUMMARY ========================================================================== Administrator's username: Administrator's PKCS #12 file: (shown only when the file is generated) <---------p12 file path---------> Administrator's certificate nickname: | Administrator's certificate database: |--- displayed only when database is not purged. <---------database file path---------> | To check the status of the subsystem: systemctl status pki-tomcatd\@.service To restart the subsystem: systemctl restart pki-tomcatd\@.service The URL for the subsystem is: https://:/ ========================================================================== Please review the patch attached for the same. --Abhishek ----- Original Message ----- From: "Abhishek Koneru" To: "pki-devel" Sent: Wednesday, July 17, 2013 5:25:36 PM Subject: [Pki-devel] [PATCH] 70 Small changes to Installation summary for 10.0 branch#645 Please review the patch which adds the client dir to the installation summary and some formatting. Also should this patch be pushed to master? --Abhishek _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0070-2-Minor-changes-in-Installation-Summary.patch Type: text/x-patch Size: 3698 bytes Desc: not available URL: From alee at redhat.com Fri Jul 19 13:44:53 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 19 Jul 2013 09:44:53 -0400 Subject: [Pki-devel] [PATCH]136 - initial framework for restful interfaces for managing profiles In-Reply-To: <51CCB135.8000907@redhat.com> References: <1372349094.2759.46.camel@localhost.localdomain> <51CCB135.8000907@redhat.com> Message-ID: <1374241493.2951.14.camel@aleeredhat.laptop> I've attached a patch that addresses most of the comments below and also also adds CLI and fixes adding/removing/editing and changing the state of profiles. As we discussed on #irc, the authentication problem is still unresolved. That is, I want to be able to do the following: GET /profiles and then in the method itself determine whether or not I have already logged in (I will have a principal) and return different results accordingly. Right now, that is not working. The only way that I can guarantee that client auth takes place and the credential is provided is by putting in a security constraint that requires /profiles/* to use client authentication. But then, I cannot do GET /profiles without authentication. It seems clientAuth=want is not working. If we cannot resolve this issue, then I will need to keep using agent/* and admin/*, which are url patterns that have security contexts. And I will have to add back GET /agent/profiles and GET /agent/profiles/{id} to see all profiles that are not visible to the EE user. Thanks, Ade On Thu, 2013-06-27 at 16:40 -0500, Endi Sukma Dewata wrote: > On 6/27/2013 11:04 AM, Ade Lee wrote: > > This adds the initial framework for viewing and managing profiles. > > At this point, only the viewing of profiles is tested. > > > > Because I make some changes to some of the objects used in Cert > > enrollment, some of the current tests involving enrollment may fail > > if they use pre-generated XML. > > > > Still, this patch is getting quite large and its time to get some eyes > > on it. > > > > The next patches will add the CLI code to view profiles and then to > > add/edit profiles. Following that, will be patches to clean up all the > > TODOs - like adding the relevant exceptions and auditing. > > > > Ade > > Some comments: > > 1. The log messages in CATest should say 'Enabled:' and 'Visible:' > because those are the attribute names being logged: > > log("Enabled: " + info.isEnabled()); > log("Visible: " + info.isVisible() + "\n\n"); > > 2. The following code in CATest can be simplified: > > ListIterator iter = > entry.getValue().getAttrs().listIterator(); > while (iter.hasNext()) { > ProfileAttribute attr = iter.next(); > > into this: > > for (ProfileAttribute attr : entry.getValue().getAttrs()) { > > Similar code exists in CertEnrollmentRequest, BasicProfile, > CertProcessor, and EnrollmentProcessor. > > 3. I don't think the ProfileAttribute should be changed to use > IDescriptor instead of Descriptor. Are there other classes implementing > IDescriptor? > > The type adapter for IDescriptor is defined as Descriptor.Adapter, but > this adapter will do a simple typecast from IDescriptor to Descriptor > and vice versa, so it probably won't work with other classes. To > properly marshal any IDescriptor into Descriptor we'd have to create a > new Descriptor object and initialize it with values obtained using using > IDescriptor methods. I'm also not sure how unmarshal would be able to > restore the original object if it's not a Descriptor. > > I think if there's no other types of descriptor (or if all descriptors > will inherit from Descriptor) then we should just use Descriptor in > ProfileAttribute. But if we need to support different descriptor types, > we need to serialization the class name as well (see PKIException.Data > class) and use a factory to recreate the proper object. > > 4. In ProfileData the inputs, outputs, and policySets attributes are > declared between the method declarations. To improve readability we > should keep the attributes in the beginning of the class before any > method declarations. > > Similar issues also happens in ProfileInput and ProfileOutput. > > 5. The ProfileData.policySets maps a String to a Vector. I think unless > there's a special need for Vector (e.g. synchronized access) we should > use a more generic and light-weight Collection instead. > > 6. The following code in BasicProfile deleteAllProfileInputs() and > deleteAllProfileInputs() can be simplified: > > Iterator iter = mInputIds.iterator(); > while (iter.hasNext()) { > String id = iter.next(); > > into this: > > for (String id : mInputIds) { > > 7. In ProfileService the listProfiles() is split into listEEProfiles() > and listAdminProfiles() to return different results based on the > visibility flag. Splitting the method doesn't prevent a user from > calling a method that he's not supposed to call. To prevent that we'd > have to configure ACLs, which adds maintenance. Also we probably have to > write different CLI to call different methods for different roles. > > Instead, we could use the original method but it should check the roles > of the user and determine the visibility flag based on that. > > 8. In ProfileService.createProfileDataInfo() the URI is constructed > using String concatenation in 2 different ways: > > if (visibleOnly) { > profileBuilder.path(profilePath.value() + "/profiles/" + > profileId); > } else { > profileBuilder.path(profilePath.value() + "/agent/profiles/" + > profileId); > } > ret.setProfileURL(profileBuilder.build().toString()); > > If we implement #7 it can be simplified like this: > > URI uri = profileBuilder.path(ProfileResource.class).path("{id}"). > build(profileId); > ret.setProfileURL(uri.toString()); > > 9. Some exceptions in ProfileService are being swallowed. I think at > least for now we should throw an exception (either make the method > throws generic Exception or wrap the exceptions in RuntimeException) so > that we know if there's a problem. Later on we can revisit this and > handle the exceptions properly. > > 10. The code in ProfileService.populateProfilePolicies() can be > simplified as follows: > > for (Map.Entry> policySet : > data.getPolicySets().entrySet()) { > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0136-1-Add-interfaces-for-managing-profiles.patch Type: text/x-patch Size: 112888 bytes Desc: not available URL: From mharmsen at redhat.com Fri Jul 19 18:39:43 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 19 Jul 2013 11:39:43 -0700 Subject: [Pki-devel] [PATCH] cloning issues in 8.1 In-Reply-To: <1373487968.1527.7.camel@aleeredhat.laptop> References: <1373487904.1527.6.camel@aleeredhat.laptop> <1373487968.1527.7.camel@aleeredhat.laptop> Message-ID: <51E987EF.9010509@redhat.com> I have attached a revised patch which includes the code from your original patch + the stuff that we worked on together + my most recent attempt at the new add_attributes() method. ACK on your original code and the code that we worked on together. Please review the code in UpdateDomainXML.java that was discussed earlier. Thanks, -- Matt On 07/10/13 13:26, Ade Lee wrote: > Opps - bug this time too: > https://bugzilla.redhat.com/show_bug.cgi?id=982320 > > On Wed, 2013-07-10 at 16:25 -0400, Ade Lee wrote: >> This is in response to >> >> Basically, there are two issues. >> >> 1. We want to use the selected CA to generate the SSL server cert. In >> the code though, for a clone, the code that sets the relevant preop >> parameter used to determine the right CA to go to - is only run after we >> issue the sslserver cert request. That means it always goes to the >> security domain CA. This code is now reversed. >> >> 2. Due to a DS bug (which has been fixed), the attributes on the >> pkiSubsystem entry in the clone CA security domain database we in lower >> case, rather than the existing case. Thats actually ok from an ldap >> point of view. We create some XML from those attributes -- just in >> case, we should make the XML matches in this case case insensitive. >> >> Please review. >> >> Thanks, >> Ade >> > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- Index: base/common/src/com/netscape/cms/authentication/TokenAuthentication.java =================================================================== --- base/common/src/com/netscape/cms/authentication/TokenAuthentication.java (revision 2619) +++ base/common/src/com/netscape/cms/authentication/TokenAuthentication.java (working copy) @@ -140,8 +140,14 @@ String sessionId = (String)authCred.get(CRED_SESSION_ID); String givenHost = (String)authCred.get("clientHost"); - String authAdminHost = sconfig.getString("securitydomain.adminhost"); - String authEEHost = sconfig.getString("securitydomain.eehost"); + String authAdminHost = sconfig.getString("securitydomain.adminhost",""); + if( authAdminHost.isEmpty() ) { + authAdminHost = sconfig.getString("securitydomain.host"); + } + String authEEHost = sconfig.getString("securitydomain.eehost",""); + if( authEEHost.isEmpty() ) { + authEEHost = sconfig.getString("securitydomain.host"); + } int authAdminPort = sconfig.getInteger("securitydomain.httpsadminport"); int authEEPort = sconfig.getInteger("securitydomain.httpseeport"); String authAdminURL = "/ca/admin/ca/tokenAuthenticate"; Index: base/common/src/com/netscape/cms/servlet/csadmin/WizardPanelBase.java =================================================================== --- base/common/src/com/netscape/cms/servlet/csadmin/WizardPanelBase.java (revision 2619) +++ base/common/src/com/netscape/cms/servlet/csadmin/WizardPanelBase.java (working copy) @@ -986,20 +986,23 @@ // is using an IP Port Separation Schema: Vector v_hostname = parser.getValuesFromContainer( nodeList.item(i), - "AdminHost" ); + "AdminHost", + true ); if ( v_hostname.isEmpty()) { // No, the Security Domain is using a Port Separation Schema v_hostname = parser.getValuesFromContainer( - nodeList.item(i), "Host" ); + nodeList.item(i), "Host", true ); } Vector v_https_admin_port = parser.getValuesFromContainer( nodeList.item(i), - "SecureAdminPort" ); + "SecureAdminPort", + true ); Vector v_domain_mgr = parser.getValuesFromContainer( nodeList.item(i), - "DomainManager" ); + "DomainManager", + true ); if( v_hostname.elementAt( 0 ).equals( hostname ) && v_https_admin_port.elementAt( 0 ).equals( Integer.toString(httpsadminport) ) ) { @@ -1064,38 +1067,44 @@ CMS.debug("Len " + len); for (int i = 0; i < len; i++) { Vector v_clone = parser.getValuesFromContainer(nodeList.item(i), - "Clone"); + "Clone", true); String clone = (String)v_clone.elementAt(0); if (clone.equalsIgnoreCase("true")) continue; Vector v_name = parser.getValuesFromContainer(nodeList.item(i), - "SubsystemName"); + "SubsystemName", true); // First, check to see if the Security Domain // is using an IP Port Separation Schema: Vector v_host = null; if( portType.equals( "UnSecurePort" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "EEHost" ); + "EEHost", + true ); } else if( portType.equals( "SecureAgentPort" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "AgentHost" ); + "AgentHost", + true ); } else if( portType.equals( "SecurePort" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "EEHost" ); + "EEHost", + true ); } else if( portType.equals( "SecureAdminPort" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "AdminHost" ); + "AdminHost", + true ); } else if( portType.equals( "SecureEEClientAuthPort" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "EEClientAuthHost" ); + "EEClientAuthHost", + true ); } if (v_host.isEmpty()) { // No, the Security Domain is using a Port Separation Schema v_host = parser.getValuesFromContainer( nodeList.item(i), - "Host" ); + "Host", + true ); } Vector v_port = parser.getValuesFromContainer(nodeList.item(i), - portType); + portType, true); v.addElement( v_name.elementAt(0) + " - https://" @@ -1161,41 +1170,47 @@ CMS.debug("Len " + len); for (int i = 0; i < len; i++) { Vector v_name = parser.getValuesFromContainer(nodeList.item(i), - "SubsystemName"); + "SubsystemName", true); // First, check to see if the Security Domain // is using an IP Port Separation Schema: Vector v_host = null; if( portType.equals( "UnSecurePort" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "EEHost" ); + "EEHost", + true ); } else if( portType.equals( "SecureAgentPort" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "AgentHost" ); + "AgentHost", + true ); } else if( portType.equals( "SecurePort" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "EEHost" ); + "EEHost", + true ); } else if( portType.equals( "SecureAdminPort" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "AdminHost" ); + "AdminHost", + true ); } else if( portType.equals( "SecureEEClientAuthPort" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "EEClientAuthHost" ); + "EEClientAuthHost", + true ); } if (v_host.isEmpty()) { // No, the Security Domain is using a Port Separation Schema v_host = parser.getValuesFromContainer( nodeList.item(i), - "Host" ); + "Host", + true ); } Vector v_port = parser.getValuesFromContainer(nodeList.item(i), - portType); + portType, true); Vector v_admin_host = parser.getValuesFromContainer( nodeList.item(i), - "AdminHost"); + "AdminHost", true); if (v_admin_host.isEmpty()) { v_admin_host = v_host; } Vector v_admin_port = parser.getValuesFromContainer(nodeList.item(i), - "SecureAdminPort"); + "SecureAdminPort", true); if( ( v_admin_host.elementAt( 0 ).equals( hostname ) ) && ( v_admin_port.elementAt( 0 ).equals( @@ -1252,20 +1267,23 @@ // is using an IP Port Separation Schema: Vector v_hostname = parser.getValuesFromContainer( nodeList.item(i), - "EEHost" ); + "EEHost", + true ); if ( v_hostname.isEmpty()) { // No, the Security Domain is using a Port Separation Schema v_hostname = parser.getValuesFromContainer( - nodeList.item(i), "Host" ); + nodeList.item(i), "Host", true ); } Vector v_https_ee_port = parser.getValuesFromContainer( nodeList.item(i), - "SecurePort" ); + "SecurePort", + true ); Vector v_https_admin_port = parser.getValuesFromContainer( nodeList.item(i), - "SecureAdminPort" ); + "SecureAdminPort", + true ); if( v_hostname.elementAt( 0 ).equals( hostname ) && v_https_ee_port.elementAt( 0 ).equals( https_ee_port ) ) { @@ -1311,14 +1329,16 @@ // is using an IP Port Separation Schema: Vector v_hostname = parser.getValuesFromContainer( nodeList.item(i), - "EEHost" ); + "EEHost", + true ); Vector v_https_admin_host = parser.getValuesFromContainer( nodeList.item(i), - "AdminHost" ); + "AdminHost", + true ); if (v_hostname.isEmpty()) { // No, the Security Domain is using a Port Separation Schema v_hostname = parser.getValuesFromContainer( - nodeList.item(i), "Host" ); + nodeList.item(i), "Host", true ); } if (v_https_admin_host.isEmpty()) { // No, the Security Domain is using a Port Separation Schema @@ -1327,7 +1347,8 @@ Vector v_https_ee_port = parser.getValuesFromContainer( nodeList.item(i), - "SecurePort" ); + "SecurePort", + true ); if( v_hostname.elementAt( 0 ).equals( hostname ) && v_https_ee_port.elementAt( 0 ).equals( https_ee_port ) ) { @@ -1375,24 +1396,30 @@ for( int i = 0; i < len; i++ ) { Vector v_admin_port = parser.getValuesFromContainer( nodeList.item(i), - "SecureAdminPort" ); + "SecureAdminPort", + true ); Vector v_port = null; if( portType.equals( "UnSecurePort" ) ) { v_port = parser.getValuesFromContainer( nodeList.item(i), - "UnSecurePort" ); + "UnSecurePort", + true ); } else if( portType.equals( "SecureAgentPort" ) ) { v_port = parser.getValuesFromContainer( nodeList.item(i), - "SecureAgentPort" ); + "SecureAgentPort", + true ); } else if( portType.equals( "SecurePort" ) ) { v_port = parser.getValuesFromContainer( nodeList.item(i), - "SecurePort" ); + "SecurePort", + true ); } else if( portType.equals( "SecureAdminPort" ) ) { v_port = parser.getValuesFromContainer( nodeList.item(i), - "SecureAdminPort" ); + "SecureAdminPort", + true ); } else if( portType.equals( "SecureEEClientAuthPort" ) ) { v_port = parser.getValuesFromContainer( nodeList.item(i), - "SecureEEClientAuthPort" ); + "SecureEEClientAuthPort", + true ); } if( ( v_port != null ) && @@ -1441,33 +1468,41 @@ for( int i = 0; i < len; i++ ) { Vector v_admin_host = parser.getValuesFromContainer( nodeList.item(i), - "AdminHost" ); + "AdminHost", + true ); if(v_admin_host.isEmpty()) { v_admin_host = parser.getValuesFromContainer( nodeList.item(i), - "Host" ); + "Host", + true ); } Vector v_admin_port = parser.getValuesFromContainer( nodeList.item(i), - "SecureAdminPort" ); + "SecureAdminPort", + true ); Vector v_host = null; if( hostType.equals( "Host" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "Host" ); + "Host", + true ); } else if( hostType.equals( "AgentHost" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "AgentHost" ); + "AgentHost", + true ); } else if( hostType.equals( "EEHost" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "EEHost" ); + "EEHost", + true ); } else if( hostType.equals( "AdminHost" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "AdminHost" ); + "AdminHost", + true ); } else if( hostType.equals( "EEClientAuthHost" ) ) { v_host = parser.getValuesFromContainer( nodeList.item(i), - "EEClientAuthHost" ); + "EEClientAuthHost", + true ); } if( ( v_admin_host.elementAt( 0 ).equals( hostname ) ) && Index: base/common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java =================================================================== --- base/common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java (revision 2619) +++ base/common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java (working copy) @@ -107,6 +107,34 @@ return status; } + private void add_attributes(String dn, LDAPModificationSet attrs) + throws LDAPException, Exception { + ILdapConnFactory connFactory = null; + LDAPConnection conn = null; + IConfigStore cs = CMS.getConfigStore(); + try { + CMS.debug("UpdateDomainXML: add_attributes - " + + "establishing ldap connection to DN '" + dn + "'"); + IConfigStore ldapConfig = cs.getSubStore("internaldb"); + connFactory = CMS.getLdapBoundConnFactory(); + connFactory.init(ldapConfig); + conn = connFactory.getConn(); + conn.modify(dn, attrs); + } finally { + try { + if ((conn != null) && (connFactory!= null)) { + CMS.debug("UpdateDomainXML: add_attributes - " + + "releasing ldap connection to DN '" + dn + "'"); + connFactory.returnConn(conn); + } + } catch (Exception e) { + CMS.debug("UpdateDomainXML: add_attributes - " + + "error releasing ldap connection to DN '" + + dn + "' - Exception " + e.toString()); + } + } + } + private String remove_attribute(String dn, LDAPModification mod) { CMS.debug("UpdateDomainXML: remove_attribute: starting dn: " + dn); String status = SUCCESS; @@ -127,6 +155,7 @@ CMS.debug("Failed to modify entry" + e.toString()); } } catch (Exception e) { + status = FAILED; CMS.debug("Failed to modify entry" + e.toString()); } finally { try { @@ -350,18 +379,6 @@ if ((eecaport != null) && (!eecaport.equals(""))) { attrs.add(new LDAPAttribute("SecureEEClientAuthPort", eecaport)); } - if ((agenthost != null) && (!agenthost.equals(""))) { - attrs.add(new LDAPAttribute("AgentHost", agenthost)); - } - if ((eehost != null) && (!eehost.equals(""))) { - attrs.add(new LDAPAttribute("EEHost", eehost)); - } - if ((adminhost != null) && (!adminhost.equals(""))) { - attrs.add(new LDAPAttribute("AdminHost", adminhost)); - } - if ((eecahost != null) && (!eecahost.equals(""))) { - attrs.add(new LDAPAttribute("EEClientAuthHost", eecahost)); - } if ((domainmgr != null) && (!domainmgr.equals(""))) { attrs.add(new LDAPAttribute("DomainManager", domainmgr.toUpperCase())); } @@ -422,7 +439,73 @@ } } } else { - status = add_to_ldap(entry, dn); + status = add_to_ldap(entry, dn); + + if (status.equals(SUCCESS)) { + CMS.debug("UpdateDomainXML: " + + "Successfully added PKI Security Domain " + + "attributes to DN '" + dn + "'"); + + // Attempt to modify this LDAP entry by + // trying to add IP Port Separation attributes + LDAPModificationSet mods = null; + mods = new LDAPModificationSet(); + if ((agenthost != null) && (!agenthost.equals(""))) { + mods.add(LDAPModification.ADD, + new LDAPAttribute("AgentHost", agenthost)); + } + if ((eehost != null) && (!eehost.equals(""))) { + mods.add(LDAPModification.ADD, + new LDAPAttribute("EEHost", eehost)); + } + if ((adminhost != null) && (!adminhost.equals(""))) { + mods.add(LDAPModification.ADD, + new LDAPAttribute("AdminHost", adminhost)); + } + if ((eecahost != null) && (!eecahost.equals(""))) { + mods.add(LDAPModification.ADD, + new LDAPAttribute("EEClientAuthHost", + eecahost)); + } + + try { + if (mods.size() > 0) { + add_attributes(dn, mods); + CMS.debug("UpdateDomainXML: " + + "Successfully added " + + "IP Port Separation Security Domain " + + "attributes to DN '" + dn + "'"); + } + } catch (LDAPException e) { + int errorCode = e.getLDAPResultCode(); + if ((errorCode == LDAPException.NO_SUCH_ATTRIBUTE) || + (errorCode == LDAPException.OBJECT_CLASS_VIOLATION)) + { + // ignore this type of error + CMS.debug("UpdateDomainXML: " + + "Unable to add " + + "IP Port Separation Security Domain " + + "attributes to DN '" + dn + + "' (server contains old schema)"); + } else { + e.printStackTrace(); + CMS.debug("UpdateDomainXML: " + + "LDAPException - Failed to add " + + "IP Port Separation Security Domain " + + "attributes to DN '" + dn + "' - " + + e.toString()); + status = FAILED; + } + } catch (Exception e) { + e.printStackTrace(); + CMS.debug("UpdateDomainXML: " + + "Exception - Failed to add " + + "IP Port Separation Security Domain " + + "attributes to DN '" + dn + "' - " + + e.toString()); + status = FAILED; + } + } } } else { @@ -447,9 +530,9 @@ for (int i = 0; i < len; i++) { Node nn = (Node) nodeList.item(i); - Vector v_name = parser.getValuesFromContainer(nn, "SubsystemName"); - Vector v_host = parser.getValuesFromContainer(nn, "Host"); - Vector v_adminport = parser.getValuesFromContainer(nn, "SecureAdminPort"); + Vector v_name = parser.getValuesFromContainer(nn, "SubsystemName", true); + Vector v_host = parser.getValuesFromContainer(nn, "Host", true); + Vector v_adminport = parser.getValuesFromContainer(nn, "SecureAdminPort", true); if ((v_name.elementAt(0).equals(name)) && (v_host.elementAt(0).equals(host)) && (v_adminport.elementAt(0).equals(adminsport))) { Node parent = nn.getParentNode(); Index: base/common/src/com/netscape/cms/servlet/csadmin/GetConfigEntries.java =================================================================== --- base/common/src/com/netscape/cms/servlet/csadmin/GetConfigEntries.java (revision 2619) +++ base/common/src/com/netscape/cms/servlet/csadmin/GetConfigEntries.java (working copy) @@ -151,8 +151,17 @@ CMS.debug("Retrieving config name=" + name); value = config.getString(name); CMS.debug("Retrieving config value=" + value); - if (value.equals("localhost")) + if (value.equals("localhost")) { value = config.getString("adminMachineName", ""); + if( value.isEmpty()) { + value = config.getString("machineName", ""); + if( value.isEmpty()) { + CMS.debug("GetConfigEntries process: " + + "WARNING - sending empty string for " + + name); + } + } + } } catch (Exception ee) { if (name.equals("internaldb.ldapauth.password")) { value = getLDAPPassword(); Index: base/common/src/com/netscape/cms/servlet/csadmin/NamePanel.java =================================================================== --- base/common/src/com/netscape/cms/servlet/csadmin/NamePanel.java (revision 2619) +++ base/common/src/com/netscape/cms/servlet/csadmin/NamePanel.java (working copy) @@ -763,8 +763,6 @@ String cstype = config.getString("preop.subsystem.select", ""); if (cstype.equals("clone")) { CMS.debug("NamePanel: clone configuration detected"); - // still need to handle SSL certificate - configCertWithTag(request, response, context, "sslserver"); String url = getURL(request, config); if (url != null && !url.equals("External CA")) { // preop.ca.url and admin port are required for setting KRA connector @@ -778,6 +776,9 @@ } updateCloneConfig(config); + + // still need to handle SSL certificate + configCertWithTag(request, response, context, "sslserver"); CMS.debug("NamePanel: clone configuration done"); return; } Index: base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java =================================================================== --- base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java (revision 2619) +++ base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java (working copy) @@ -291,6 +291,11 @@ } catch (Exception e) { } + if (hostname == null || hostname.length() == 0) { + cs.putString("preop.database.errorString", "Host is empty string"); + throw new IOException("Host is empty string"); + } + if (select.equals("clone")) { String masterhost = ""; String masterport = ""; @@ -302,26 +307,19 @@ } catch (Exception e) { } - //get the real host name - String realhostname = ""; if (hostname.equals("localhost")) { - try { - realhostname = cs.getString("adminMachineName", ""); - } catch (Exception ee) { - } + cs.putString("preop.database.errorString", + "Use FQDN instead of localhost"); + throw new IOException("Use FQDN instead of localhost"); } - if (masterhost.equals(realhostname) && masterport.equals(portStr)) + + if (masterhost.equals(hostname) && masterport.equals(portStr)) throw new IOException("Master and clone must not share the same internal database"); if (!masterbasedn.equals(basedn)) throw new IOException("Master and clone should have the same base DN"); } - if (hostname == null || hostname.length() == 0) { - cs.putString("preop.database.errorString", "Host is empty string"); - throw new IOException("Host is empty string"); - } - if (portStr != null && portStr.length() > 0) { int port = -1; Index: base/util/src/com/netscape/cmsutil/xml/XMLObject.java =================================================================== --- base/util/src/com/netscape/cmsutil/xml/XMLObject.java (revision 2619) +++ base/util/src/com/netscape/cmsutil/xml/XMLObject.java (working copy) @@ -122,12 +122,17 @@ } public Vector getValuesFromContainer(Node container, String tagname) { + return getValuesFromContainer(container, tagname, false); + } + + public Vector getValuesFromContainer(Node container, String tagname, boolean ignoreCase) { Vector v = new Vector(); NodeList c = container.getChildNodes(); int len = c.getLength(); for (int i=0; i 0) { Node grandchild = grandchildren.item(0); From mharmsen at redhat.com Fri Jul 19 21:32:58 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 19 Jul 2013 14:32:58 -0700 Subject: [Pki-devel] [PATCH] cloning issues in 8.1 In-Reply-To: <51E987EF.9010509@redhat.com> References: <1373487904.1527.6.camel@aleeredhat.laptop> <1373487968.1527.7.camel@aleeredhat.laptop> <51E987EF.9010509@redhat.com> Message-ID: <51E9B08A.7010402@redhat.com> On 07/19/13 11:39, Matthew Harmsen wrote: > I have attached a revised patch which includes the code from your > original patch + the stuff that we worked on together + my most recent > attempt at the new add_attributes() method. > > ACK on your original code and the code that we worked on together. > > Please review the code in UpdateDomainXML.java that was discussed > earlier. > ACKed by alee and checked in to PKI_8_1_ERRATA_BRANCH and PKI_8_BRANCH. -- Matt > Thanks, > -- Matt > > On 07/10/13 13:26, Ade Lee wrote: >> Opps - bug this time too: >> https://bugzilla.redhat.com/show_bug.cgi?id=982320 >> >> On Wed, 2013-07-10 at 16:25 -0400, Ade Lee wrote: >>> This is in response to >>> >>> Basically, there are two issues. >>> >>> 1. We want to use the selected CA to generate the SSL server cert. In >>> the code though, for a clone, the code that sets the relevant preop >>> parameter used to determine the right CA to go to - is only run >>> after we >>> issue the sslserver cert request. That means it always goes to the >>> security domain CA. This code is now reversed. >>> >>> 2. Due to a DS bug (which has been fixed), the attributes on the >>> pkiSubsystem entry in the clone CA security domain database we in lower >>> case, rather than the existing case. Thats actually ok from an ldap >>> point of view. We create some XML from those attributes -- just in >>> case, we should make the XML matches in this case case insensitive. >>> >>> Please review. >>> >>> Thanks, >>> Ade >>> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Mon Jul 22 13:29:29 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 22 Jul 2013 08:29:29 -0500 Subject: [Pki-devel] [PATCH] 278 Storing authentication info in session. Message-ID: <51ED33B9.2040206@redhat.com> The authenticator configuration has been modified to store the authentication info in the session so it can be used by other servlets. An update script has been added to update the configuration in existing instances. The SSLAuthenticatorWithFalback was modified to propagate the configuration to the actual authenticator handling the request. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0278-Storing-authentication-info-in-session.patch Type: text/x-patch Size: 8914 bytes Desc: not available URL: From edewata at redhat.com Mon Jul 22 13:30:50 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 22 Jul 2013 08:30:50 -0500 Subject: [Pki-devel] [PATCH]136 - initial framework for restful interfaces for managing profiles In-Reply-To: <1374241493.2951.14.camel@aleeredhat.laptop> References: <1372349094.2759.46.camel@localhost.localdomain> <51CCB135.8000907@redhat.com> <1374241493.2951.14.camel@aleeredhat.laptop> Message-ID: <51ED340A.7060006@redhat.com> On 7/19/2013 8:44 AM, Ade Lee wrote: > GET /profiles and then in the method itself determine whether or not I > have already logged in (I will have a principal) and return different > results accordingly. > > Right now, that is not working. The only way that I can guarantee that > client auth takes place and the credential is provided is by putting in > a security constraint that requires /profiles/* to use client > authentication. But then, I cannot do GET /profiles without > authentication. It seems clientAuth=want is not working. Some comments: 1. It looks like the current clientAuth setting is fine, but the SSL authenticator needs to be configured to use session. See the alwaysUseSession parameter in this page: http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html. I posted patch #278 to add this parameter. Then the security constraint can be configured without to allow anonymous access: Profiles /rest/profiles/* CONFIDENTIAL I've tested this with profile-find, it will return different number of results depending on the authentication. This way we won't need to use separate agent/admin interface. 2. For the profile-find output, I think it would be useful to show some basic info such as profile name and description in addition to the ID and URL. 3. The profile-show command stores the entire profile into an output file, it doesn't show anything to the screen. I think it would be useful and more consistent to show the profile summary such as id, name, description, input and output attribute names, URL. Then people can optionally specify --output download the entire file. 4. Does the profile subsystem support renaming a profile? The profile-mod may need to take 2 parameters: the old profile name and an input file containing the new profile name and the new attributes. 5. Some methods in ProfileService would catch and swallow the exception. It might be better for now to throw a generic exception or just don't catch at all. This way the client will know if there's an error. In the future we can revisit the code to throw more specific errors. -- Endi S. Dewata From edewata at redhat.com Mon Jul 22 13:51:09 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 22 Jul 2013 08:51:09 -0500 Subject: [Pki-devel] [PATCH] 273 Added option to override compose work directory. In-Reply-To: <51E5BF14.5010607@redhat.com> References: <51E5BF14.5010607@redhat.com> Message-ID: <51ED38CD.4030203@redhat.com> On 7/16/2013 4:45 PM, Endi Sukma Dewata wrote: > Currently the compose scripts always use a fixed work directory called > "packages" to do the build. To provide more flexibility, a new optional > parameter has been added to allow overriding the work directory. Fixed missing changes in compose_dogtag_pki_meta_packages. The compose_dogtag_pki_theme_packages is already changed. ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Jul 22 14:09:08 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 22 Jul 2013 09:09:08 -0500 Subject: [Pki-devel] [PATCH] 274 Reorganized deployment tools. In-Reply-To: <51E5C646.20307@redhat.com> References: <51E5C646.20307@redhat.com> Message-ID: <51ED3D04.50305@redhat.com> On 7/16/2013 5:16 PM, Endi Sukma Dewata wrote: > The pkispawn and pkidestroy scripts have been moved into sbin folder. > The Python deployment library and the scriptlets were moved into > pki.server.deployment and pki.server.deployment.scriptlets packages, > respectively. ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Jul 22 14:09:53 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 22 Jul 2013 09:09:53 -0500 Subject: [Pki-devel] [PATCH] 276 Cleaned up code to install man pages. In-Reply-To: <51E6D040.2050808@redhat.com> References: <51E6D040.2050808@redhat.com> Message-ID: <51ED3D31.8030803@redhat.com> On 7/17/2013 12:11 PM, Endi Sukma Dewata wrote: > The code to install man pages in the spec file and CMake scripts > has been cleaned up for clarity. > > Ticket #582 > > Note: Patch #271 will need to be rebased. ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Jul 22 14:13:05 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 22 Jul 2013 09:13:05 -0500 Subject: [Pki-devel] [PATCH] 277 Fixed dependency issue on CMSRequest. In-Reply-To: <51E70A54.2090802@redhat.com> References: <51E70A54.2090802@redhat.com> Message-ID: <51ED3DF1.2090202@redhat.com> On 7/17/2013 4:19 PM, Endi Sukma Dewata wrote: > The CMSRequest is a server class but it's used by the ICommandQueue > that belongs in the base package. To fix the dependency issue the > CMSRequest has been refactored to implement a new interface > ICMSRequest in the base package. Some constants in CMSRequest have > also been moved into ICMSRequest. All code referencing CMSRequest > has been adjusted accordingly. ACKed by Ade. Pushed to master. -- Endi S. Dewata From alee at redhat.com Mon Jul 22 15:12:01 2013 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Jul 2013 11:12:01 -0400 Subject: [Pki-devel] [PATCH]136 - initial framework for restful interfaces for managing profiles In-Reply-To: <51ED340A.7060006@redhat.com> References: <1372349094.2759.46.camel@localhost.localdomain> <51CCB135.8000907@redhat.com> <1374241493.2951.14.camel@aleeredhat.laptop> <51ED340A.7060006@redhat.com> Message-ID: <1374505921.2951.51.camel@aleeredhat.laptop> Great find on the Session variable. Agreed on all of the below. I will fix in separate subsequent patches. Pushing the current patch to master now. Ade On Mon, 2013-07-22 at 08:30 -0500, Endi Sukma Dewata wrote: > On 7/19/2013 8:44 AM, Ade Lee wrote: > > GET /profiles and then in the method itself determine whether or not I > > have already logged in (I will have a principal) and return different > > results accordingly. > > > > Right now, that is not working. The only way that I can guarantee that > > client auth takes place and the credential is provided is by putting in > > a security constraint that requires /profiles/* to use client > > authentication. But then, I cannot do GET /profiles without > > authentication. It seems clientAuth=want is not working. > > Some comments: > > 1. It looks like the current clientAuth setting is fine, but the SSL > authenticator needs to be configured to use session. See the > alwaysUseSession parameter in this page: > http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html. I posted > patch #278 to add this parameter. > > Then the security constraint can be configured without > to allow anonymous access: > > > > Profiles > /rest/profiles/* > > > CONFIDENTIAL > > > > I've tested this with profile-find, it will return different number of > results depending on the authentication. This way we won't need to use > separate agent/admin interface. > > 2. For the profile-find output, I think it would be useful to show some > basic info such as profile name and description in addition to the ID > and URL. > > 3. The profile-show command stores the entire profile into an output > file, it doesn't show anything to the screen. I think it would be useful > and more consistent to show the profile summary such as id, name, > description, input and output attribute names, URL. Then people can > optionally specify --output download the entire file. > > 4. Does the profile subsystem support renaming a profile? The > profile-mod may need to take 2 parameters: the old profile name and an > input file containing the new profile name and the new attributes. > > 5. Some methods in ProfileService would catch and swallow the exception. > It might be better for now to throw a generic exception or just don't > catch at all. This way the client will know if there's an error. In the > future we can revisit the code to throw more specific errors. > From edewata at redhat.com Mon Jul 22 21:40:54 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 22 Jul 2013 16:40:54 -0500 Subject: [Pki-devel] [PATCH] 271 Added man pages for upgrade tools. In-Reply-To: <51DD7E19.9070401@redhat.com> References: <51DD7E19.9070401@redhat.com> Message-ID: <51EDA6E6.1030008@redhat.com> On 7/10/2013 10:30 AM, Endi Sukma Dewata wrote: > New man pages have been added for pki-upgrade and pki-server-upgrade. > The spec file and build scripts have been updated accordingly. > > Ticket #582 ACKed by Ade, included Deon's changes, rebased, pushed to master and 10.0.x branch. -- Endi S. Dewata From jmagne at redhat.com Mon Jul 22 22:02:06 2013 From: jmagne at redhat.com (John Magne) Date: Mon, 22 Jul 2013 18:02:06 -0400 (EDT) Subject: [Pki-devel] [PATCH] 275 Fixed token authentication problem on RHEL. In-Reply-To: <51E6C839.7040605@redhat.com> References: <51E6C839.7040605@redhat.com> Message-ID: <917361946.5096277.1374530526469.JavaMail.root@redhat.com> ACK: Just a quick question though. Was there a reason not to create another initCertDB method for the new class the code was moved to, instead of putting it inline? ----- Original Message ----- From: "Endi Sukma Dewata" To: "pki-devel" Sent: Wednesday, July 17, 2013 9:37:13 AM Subject: [Pki-devel] [PATCH] 275 Fixed token authentication problem on RHEL. The CryptoManager.initialize() and CryptoToken.login() invocation has been moved into the main program as a workaround for the authentication problem on RHEL and to ensure proper initialization in general. Bugzilla #985111 -- Endi S. Dewata _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Mon Jul 22 23:06:34 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 22 Jul 2013 18:06:34 -0500 Subject: [Pki-devel] [PATCH] 275 Fixed token authentication problem on RHEL. In-Reply-To: <917361946.5096277.1374530526469.JavaMail.root@redhat.com> References: <51E6C839.7040605@redhat.com> <917361946.5096277.1374530526469.JavaMail.root@redhat.com> Message-ID: <51EDBAFA.9060000@redhat.com> On 7/22/2013 5:02 PM, John Magne wrote: > ACK: > > Just a quick question though. Was there a reason not to create > another initCertDB method for the new class the code was moved to, > instead ofputting it inline? It could be done that way, but it's not necessary because for now the code will only be called by MainCLI. The MainCLI.init() doesn't contain a lot of stuff so I thought I'd just put it in there. Ideally, once the actual problem is fixed I'd like to restore the PKIClient.initCertDatabase() so it can be reused by other programs. Pushed to master and 10.0.x branch. Thanks. -- Endi S. Dewata From akoneru at redhat.com Tue Jul 23 01:32:59 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 22 Jul 2013 21:32:59 -0400 Subject: [Pki-devel] [PATCH] 71 Patch for ticket 316- Adding pylint to the build process Message-ID: <1374543179.31615.14.camel@akoneru.redhat.com> Please review the patch which adds a script and also the pylint configuration file to the code tree. The script is called in the compose script for core packages before the actual packaging is done. If any errors or warnings are reported by pylint, the build fails. I did not add pylint as part of build-requires in the spec file for pki-core, but have put a check in the script to bypass trying to scan if pylint is not installed but with a comment stating the same in the log. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0071-Adding-pylint-scan-to-the-build.patch Type: text/x-patch Size: 11955 bytes Desc: not available URL: From edewata at redhat.com Tue Jul 23 20:40:56 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Jul 2013 15:40:56 -0500 Subject: [Pki-devel] [PATCH] 279 Fixed NullPointerException with external CA. Message-ID: <51EEEA58.8020103@redhat.com> The deployment tool has been modified to overwrite the pki_issuing_ca when configuring with external CA regardless of the default value. Bugzilla #986901 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0279-Fixed-NullPointerException-with-external-CA.patch Type: text/x-patch Size: 1318 bytes Desc: not available URL: From edewata at redhat.com Tue Jul 23 21:03:26 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Jul 2013 16:03:26 -0500 Subject: [Pki-devel] [PATCH] 279 Fixed NullPointerException with external CA. In-Reply-To: <51EEEA58.8020103@redhat.com> References: <51EEEA58.8020103@redhat.com> Message-ID: <51EEEF9E.6010707@redhat.com> On 7/23/2013 3:40 PM, Endi Sukma Dewata wrote: > The deployment tool has been modified to overwrite the pki_issuing_ca > when configuring with external CA regardless of the default value. > > Bugzilla #986901 ACKed by Ade. Pushed to master and 10.0 branch. -- Endi S. Dewata From mharmsen at redhat.com Wed Jul 24 00:25:23 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 23 Jul 2013 17:25:23 -0700 Subject: [Pki-devel] [PATCH] Bugzilla Bug #975939 - RHCS 8.1: "END CERTIFICATE" tag is not on it's own line Message-ID: <51EF1EF3.30808@redhat.com> Please review the attached patch for the following bug: * *Bugzilla Bug #975939* -RHCS 8.1: "END CERTIFICATE" tag is not on it's own line This bug refers to a display problem in the DRM Transport Certificate. Before the patch was applied, 'https://pki-ip-host.example.com:10443/kra/agent/kra/displayTransportCert' displayed the following: -----BEGIN CERTIFICATE----- MIIDvjCCAqagAwIBAgIBCDANBgkqhkiG9w0BAQsFADBRMR4wHAYDVQQKExVEc2Rl dlNqY1JlZGhhdCBEb21haW4xDzANBgNVBAsTBnBraS1jYTEeMBwGA1UEAxMVQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEzMDcyNDA0MzM0OFoXDTE1MDcxNDA0MzM0 OFowVjEeMBwGA1UEChMVRHNkZXZTamNSZWRoYXQgRG9tYWluMRAwDgYDVQQLEwdw a2kta3JhMSIwIAYDVQQDExlEUk0gVHJhbnNwb3J0IENlcnRpZmljYXRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw/rFaEIcVRaQOGcV6bAAg/I1IKsp tx3iT/QXUhbotl+rIXCRvM1057RBKdTSYVALhfYnfbEUg4bfNX6RzIxqPCIXrwl9 xM3Itk6st3OOMpMGsyGUh0BctMJeOjMXy6U/djL51Mhr4oKBwwoQbOr944hlI7hp 8u9PEBmfTGeWps18oz+dLPnsIq5rt9U75o9BTZ1+zOkyyLh+U5SsqqAzwd7gIRVt v5DuA03kTTGnd4/0D7J8bJ9xeBeBWlybLwYc4xMndwApLjiluzHioGHWg3gg+dBP mlnaMdD9KpNjingumcGZNf8RYG3cb/u9svo4b21iNVOpC4LDW6InPWS2fQIDAQAB o4GbMIGYMB8GA1UdIwQYMBaAFDys38nHtDFshY0Lh2+RFp2FCeYOMFAGCCsGAQUF BwEBBEQwQjBABggrBgEFBQcwAYY0aHR0cDovL3BraS1pcC1ob3N0LmRzZGV2LnNq Yy5yZWRoYXQuY29tOjkxODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwEwYDVR0l BAwwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAD7A1cfx88tXim+durkL uSwJl5EOS0ai5WKXh5Ov4Ir2sWHb/8+FIPtxlW12y3zN6076q1bsyOLdw1TSCaA1 iYhvoEED+uC52kGOGigXJRM3w01/+dG6VPkgcvTSmt1MFnVJHhhmqNGGXZIOCazD aUClEzUetOq4ok6E6vyM3LU8iVHtMC7TaA358vrAxDhsCqlZuR8NPAsuwx15S28P nngFikjbeBsuem96Q35uSB61Tp7V3rO7J7A7hSliudfmSJwDKjBBgIkjC1wgOTjm PVjq9Ss49t1ZD9mmwx5B9DNBZhh1TGPPx8MOVThhLHnw9PuBmfW2eTsmVXsDFVNe 0j8=-----END CERTIFICATE----- After the patch was applied, 'https://pki-ip-host.example.com:10443/kra/agent/kra/displayTransportCert' displayed the following: -----BEGIN CERTIFICATE----- MIIDvjCCAqagAwIBAgIBCDANBgkqhkiG9w0BAQsFADBRMR4wHAYDVQQKExVEc2Rl dlNqY1JlZGhhdCBEb21haW4xDzANBgNVBAsTBnBraS1jYTEeMBwGA1UEAxMVQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEzMDcyNDA0MzM0OFoXDTE1MDcxNDA0MzM0 OFowVjEeMBwGA1UEChMVRHNkZXZTamNSZWRoYXQgRG9tYWluMRAwDgYDVQQLEwdw a2kta3JhMSIwIAYDVQQDExlEUk0gVHJhbnNwb3J0IENlcnRpZmljYXRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw/rFaEIcVRaQOGcV6bAAg/I1IKsp tx3iT/QXUhbotl+rIXCRvM1057RBKdTSYVALhfYnfbEUg4bfNX6RzIxqPCIXrwl9 xM3Itk6st3OOMpMGsyGUh0BctMJeOjMXy6U/djL51Mhr4oKBwwoQbOr944hlI7hp 8u9PEBmfTGeWps18oz+dLPnsIq5rt9U75o9BTZ1+zOkyyLh+U5SsqqAzwd7gIRVt v5DuA03kTTGnd4/0D7J8bJ9xeBeBWlybLwYc4xMndwApLjiluzHioGHWg3gg+dBP mlnaMdD9KpNjingumcGZNf8RYG3cb/u9svo4b21iNVOpC4LDW6InPWS2fQIDAQAB o4GbMIGYMB8GA1UdIwQYMBaAFDys38nHtDFshY0Lh2+RFp2FCeYOMFAGCCsGAQUF BwEBBEQwQjBABggrBgEFBQcwAYY0aHR0cDovL3BraS1pcC1ob3N0LmRzZGV2LnNq Yy5yZWRoYXQuY29tOjkxODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwEwYDVR0l BAwwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAD7A1cfx88tXim+durkL uSwJl5EOS0ai5WKXh5Ov4Ir2sWHb/8+FIPtxlW12y3zN6076q1bsyOLdw1TSCaA1 iYhvoEED+uC52kGOGigXJRM3w01/+dG6VPkgcvTSmt1MFnVJHhhmqNGGXZIOCazD aUClEzUetOq4ok6E6vyM3LU8iVHtMC7TaA358vrAxDhsCqlZuR8NPAsuwx15S28P nngFikjbeBsuem96Q35uSB61Tp7V3rO7J7A7hSliudfmSJwDKjBBgIkjC1wgOTjm PVjq9Ss49t1ZD9mmwx5B9DNBZhh1TGPPx8MOVThhLHnw9PuBmfW2eTsmVXsDFVNe 0j8= -----END CERTIFICATE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: redhat.diff Type: text/x-patch Size: 658 bytes Desc: not available URL: From jmagne at redhat.com Wed Jul 24 00:27:43 2013 From: jmagne at redhat.com (John Magne) Date: Tue, 23 Jul 2013 20:27:43 -0400 (EDT) Subject: [Pki-devel] [PATCH] Bugzilla Bug #975939 - RHCS 8.1: "END CERTIFICATE" tag is not on it's own line In-Reply-To: <51EF1EF3.30808@redhat.com> References: <51EF1EF3.30808@redhat.com> Message-ID: <436997694.5775662.1374625663051.JavaMail.root@redhat.com> ack ----- Original Message ----- From: "Matthew Harmsen" To: "pki-devel" Sent: Tuesday, July 23, 2013 5:25:23 PM Subject: [Pki-devel] [PATCH] Bugzilla Bug #975939 - RHCS 8.1: "END CERTIFICATE" tag is not on it's own line Please review the attached patch for the following bug: * Bugzilla Bug #975939 - RHCS 8.1: "END CERTIFICATE" tag is not on it's own line This bug refers to a display problem in the DRM Transport Certificate. Before the patch was applied, ' https://pki-ip-host.example.com:10443/kra/agent/kra/displayTransportCert ' displayed the following: -----BEGIN CERTIFICATE----- MIIDvjCCAqagAwIBAgIBCDANBgkqhkiG9w0BAQsFADBRMR4wHAYDVQQKExVEc2Rl dlNqY1JlZGhhdCBEb21haW4xDzANBgNVBAsTBnBraS1jYTEeMBwGA1UEAxMVQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEzMDcyNDA0MzM0OFoXDTE1MDcxNDA0MzM0 OFowVjEeMBwGA1UEChMVRHNkZXZTamNSZWRoYXQgRG9tYWluMRAwDgYDVQQLEwdw a2kta3JhMSIwIAYDVQQDExlEUk0gVHJhbnNwb3J0IENlcnRpZmljYXRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw/rFaEIcVRaQOGcV6bAAg/I1IKsp tx3iT/QXUhbotl+rIXCRvM1057RBKdTSYVALhfYnfbEUg4bfNX6RzIxqPCIXrwl9 xM3Itk6st3OOMpMGsyGUh0BctMJeOjMXy6U/djL51Mhr4oKBwwoQbOr944hlI7hp 8u9PEBmfTGeWps18oz+dLPnsIq5rt9U75o9BTZ1+zOkyyLh+U5SsqqAzwd7gIRVt v5DuA03kTTGnd4/0D7J8bJ9xeBeBWlybLwYc4xMndwApLjiluzHioGHWg3gg+dBP mlnaMdD9KpNjingumcGZNf8RYG3cb/u9svo4b21iNVOpC4LDW6InPWS2fQIDAQAB o4GbMIGYMB8GA1UdIwQYMBaAFDys38nHtDFshY0Lh2+RFp2FCeYOMFAGCCsGAQUF BwEBBEQwQjBABggrBgEFBQcwAYY0aHR0cDovL3BraS1pcC1ob3N0LmRzZGV2LnNq Yy5yZWRoYXQuY29tOjkxODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwEwYDVR0l BAwwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAD7A1cfx88tXim+durkL uSwJl5EOS0ai5WKXh5Ov4Ir2sWHb/8+FIPtxlW12y3zN6076q1bsyOLdw1TSCaA1 iYhvoEED+uC52kGOGigXJRM3w01/+dG6VPkgcvTSmt1MFnVJHhhmqNGGXZIOCazD aUClEzUetOq4ok6E6vyM3LU8iVHtMC7TaA358vrAxDhsCqlZuR8NPAsuwx15S28P nngFikjbeBsuem96Q35uSB61Tp7V3rO7J7A7hSliudfmSJwDKjBBgIkjC1wgOTjm PVjq9Ss49t1ZD9mmwx5B9DNBZhh1TGPPx8MOVThhLHnw9PuBmfW2eTsmVXsDFVNe 0j8=-----END CERTIFICATE----- After the patch was applied, ' https://pki-ip-host.example.com:10443/kra/agent/kra/displayTransportCert ' displayed the following: -----BEGIN CERTIFICATE----- MIIDvjCCAqagAwIBAgIBCDANBgkqhkiG9w0BAQsFADBRMR4wHAYDVQQKExVEc2Rl dlNqY1JlZGhhdCBEb21haW4xDzANBgNVBAsTBnBraS1jYTEeMBwGA1UEAxMVQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEzMDcyNDA0MzM0OFoXDTE1MDcxNDA0MzM0 OFowVjEeMBwGA1UEChMVRHNkZXZTamNSZWRoYXQgRG9tYWluMRAwDgYDVQQLEwdw a2kta3JhMSIwIAYDVQQDExlEUk0gVHJhbnNwb3J0IENlcnRpZmljYXRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw/rFaEIcVRaQOGcV6bAAg/I1IKsp tx3iT/QXUhbotl+rIXCRvM1057RBKdTSYVALhfYnfbEUg4bfNX6RzIxqPCIXrwl9 xM3Itk6st3OOMpMGsyGUh0BctMJeOjMXy6U/djL51Mhr4oKBwwoQbOr944hlI7hp 8u9PEBmfTGeWps18oz+dLPnsIq5rt9U75o9BTZ1+zOkyyLh+U5SsqqAzwd7gIRVt v5DuA03kTTGnd4/0D7J8bJ9xeBeBWlybLwYc4xMndwApLjiluzHioGHWg3gg+dBP mlnaMdD9KpNjingumcGZNf8RYG3cb/u9svo4b21iNVOpC4LDW6InPWS2fQIDAQAB o4GbMIGYMB8GA1UdIwQYMBaAFDys38nHtDFshY0Lh2+RFp2FCeYOMFAGCCsGAQUF BwEBBEQwQjBABggrBgEFBQcwAYY0aHR0cDovL3BraS1pcC1ob3N0LmRzZGV2LnNq Yy5yZWRoYXQuY29tOjkxODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwEwYDVR0l BAwwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAD7A1cfx88tXim+durkL uSwJl5EOS0ai5WKXh5Ov4Ir2sWHb/8+FIPtxlW12y3zN6076q1bsyOLdw1TSCaA1 iYhvoEED+uC52kGOGigXJRM3w01/+dG6VPkgcvTSmt1MFnVJHhhmqNGGXZIOCazD aUClEzUetOq4ok6E6vyM3LU8iVHtMC7TaA358vrAxDhsCqlZuR8NPAsuwx15S28P nngFikjbeBsuem96Q35uSB61Tp7V3rO7J7A7hSliudfmSJwDKjBBgIkjC1wgOTjm PVjq9Ss49t1ZD9mmwx5B9DNBZhh1TGPPx8MOVThhLHnw9PuBmfW2eTsmVXsDFVNe 0j8= -----END CERTIFICATE----- _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Wed Jul 24 22:41:46 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 24 Jul 2013 15:41:46 -0700 Subject: [Pki-devel] [PATCH] DOGTAG 10.0: Bugzilla Bug #986506 - Need to determine RPM packages to be excluded from compose . . . Message-ID: <51F0582A.8090801@redhat.com> Please review the attached patch for Dogtag 10.0 which addresses the following bug: * *Bugzilla Bug #986506* -Need to determine RPM packages to be excluded from compose . . . The attached patch generates the following RPMS using '*pki/scripts/compose_pki_core_packages hybrid_rpms*' on an x86_64 Fedora 18 machine: * pki-base-10.0.4-0.4.el5pki.noarch.rpm * pki-ca-10.0.4-0.4.el5pki.noarch.rpm * pki-core-debuginfo-10.0.4-0.4.el5pki.x86_64.rpm * pki-javadoc-10.0.4-0.4.el5pki.noarch.rpm * *pki-kra-10.0.4-0.4.el5pki.noarch.rpm* * *pki-ocsp-10.0.4-0.4.el5pki.noarch.rpm* * pki-server-10.0.4-0.4.el5pki.noarch.rpm * pki-symkey-10.0.4-0.4.el5pki.x86_64.rpm * *pki-tks-10.0.4-0.4.el5pki.noarch.rpm* * pki-tools-10.0.4-0.4.el5pki.x86_64.rpm and the following RPMS using '*pki/scripts/compose_pki_core_packages hybrid_rpms*' on an x86_64 RHEL 7 machine: * pki-base-10.0.4-0.4.el5pki.noarch.rpm * pki-ca-10.0.4-0.4.el5pki.noarch.rpm * pki-core-debuginfo-10.0.4-0.4.el5pki.x86_64.rpm * pki-javadoc-10.0.4-0.4.el5pki.noarch.rpm * pki-server-10.0.4-0.4.el5pki.noarch.rpm * pki-symkey-10.0.4-0.4.el5pki.x86_64.rpm * pki-tools-10.0.4-0.4.el5pki.x86_64.rpm -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20130724-Exclude-pki-kra-pki-ocsp-and-pki-tks-from-rhel-7.patch Type: text/x-patch Size: 12026 bytes Desc: not available URL: From edewata at redhat.com Wed Jul 24 23:52:58 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 24 Jul 2013 18:52:58 -0500 Subject: [Pki-devel] [PATCH] DOGTAG 10.0: Bugzilla Bug #986506 - Need to determine RPM packages to be excluded from compose . . . In-Reply-To: <51F0582A.8090801@redhat.com> References: <51F0582A.8090801@redhat.com> Message-ID: <51F068DA.5010307@redhat.com> As mentioned over IRC, just one minor thing, the pki-symkey dependency in pki-tks can be removed because it's already added to pki-server. Everything else is good. ACK. -- Endi S. Dewata On 7/24/2013 5:41 PM, Matthew Harmsen wrote: > Please review the attached patch for Dogtag 10.0 which addresses the > following bug: > > * *Bugzilla Bug #986506* > -Need to > determine RPM packages to be excluded from compose . . . > > The attached patch generates the following RPMS using > '*pki/scripts/compose_pki_core_packages hybrid_rpms*' on an x86_64 > Fedora 18 machine: > > * pki-base-10.0.4-0.4.el5pki.noarch.rpm > * pki-ca-10.0.4-0.4.el5pki.noarch.rpm > * pki-core-debuginfo-10.0.4-0.4.el5pki.x86_64.rpm > * pki-javadoc-10.0.4-0.4.el5pki.noarch.rpm > * *pki-kra-10.0.4-0.4.el5pki.noarch.rpm* > * *pki-ocsp-10.0.4-0.4.el5pki.noarch.rpm* > * pki-server-10.0.4-0.4.el5pki.noarch.rpm > * pki-symkey-10.0.4-0.4.el5pki.x86_64.rpm > * *pki-tks-10.0.4-0.4.el5pki.noarch.rpm* > * pki-tools-10.0.4-0.4.el5pki.x86_64.rpm > > and the following RPMS using '*pki/scripts/compose_pki_core_packages > hybrid_rpms*' on an x86_64 RHEL 7 machine: > > * pki-base-10.0.4-0.4.el5pki.noarch.rpm > * pki-ca-10.0.4-0.4.el5pki.noarch.rpm > * pki-core-debuginfo-10.0.4-0.4.el5pki.x86_64.rpm > * pki-javadoc-10.0.4-0.4.el5pki.noarch.rpm > * pki-server-10.0.4-0.4.el5pki.noarch.rpm > * pki-symkey-10.0.4-0.4.el5pki.x86_64.rpm > * pki-tools-10.0.4-0.4.el5pki.x86_64.rpm > > -- Matt > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > From alee at redhat.com Thu Jul 25 03:38:07 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 24 Jul 2013 23:38:07 -0400 Subject: [Pki-devel] [PATCH] Back port proxy port logic to 8.1 Message-ID: <1374723487.30744.16.camel@aleeredhat.laptop> We need to back port the proxy port configuration to RHCS 8.1. This addresses https://bugzilla.redhat.com/show_bug.cgi?id=988189 This is different from the original fix in that we allow the specification of different ports for each interface. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: proxy.patch Type: text/x-patch Size: 46597 bytes Desc: not available URL: From alee at redhat.com Fri Jul 26 17:26:07 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 26 Jul 2013 13:26:07 -0400 Subject: [Pki-devel] [PATCH] 71 Patch for ticket 316- Adding pylint to the build process In-Reply-To: <1374543179.31615.14.camel@akoneru.redhat.com> References: <1374543179.31615.14.camel@akoneru.redhat.com> Message-ID: <1374859567.2341.63.camel@aleeredhat.laptop> A few questions/ comments: 1. In your build, you create a pylintscan directory within the source tree under pki. I would prefer this to take place in the build area so that it does not clutter up your source tree. The pylintscan is a build artifact. 2. Do you need to remove the directory prior to each run? 3. What parts of the pylintrc are not default? ie. which parts did you change? 4. I noticed that you added JSONEncoder to the pylintrc as a class for which private members should not be checked. Does that allow you to eliminate the comment to # pylint: disable-msg=E0202 in encoder.py? 5. Can you explain the rationale for ignoring W0511 and W0105? 6. I would prefer to not ignore Convention, refactor etc. and to have these show up in the pylint reports. Based on the return code for pylint, you can have the build fail only if the bits for errors and warnings are set. 7. The pylint command line seems to have all the python executables listed -- is this required? It means having to update this list every time an executable is added, which is a step that can easily be missed. Can you just point the scan to the top level directory? 8. Similarly to the point above, is there a way to scan the source tree to find all the python code? On Mon, 2013-07-22 at 21:32 -0400, Abhishek Koneru wrote: > Please review the patch which adds a script and also the pylint > configuration file to the code tree. The script is called in the compose > script for core packages before the actual packaging is done. If any > errors or warnings are reported by pylint, the build fails. > > I did not add pylint as part of build-requires in the spec file for > pki-core, but have put a check in the script to bypass trying to scan if > pylint is not installed but with a comment stating the same in the log. > > --Abhishek > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Fri Jul 26 18:12:42 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 26 Jul 2013 14:12:42 -0400 Subject: [Pki-devel] Announcing the release of Dogtag 10.0.4 Message-ID: <1374862362.2341.74.camel@aleeredhat.laptop> The Dogtag team is proud to announce the fourth errata build for Dogtag 10.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repositories. Please try them out and provide karma to move them to the F18 and F19 stable repositories. == Build Versions == pki-core-10.0.4-1 pki-ra-10.0.4-1 pki-tps-10.0.4-1 dogtag-pki-10.0.4-1 dogtag-pki-theme-10.0.4-1 pki-console-10.0.4-1 == Highlights since Dogtag 10.0.3 == * Enhanced pkispawn to provide automatic backup and restore mechanism for files modified during the upgrade process. * Improved the summary information at the end of pkispawn to include, among other things, the location of the agent PKCS #12 file. * Fixes to pkispawn and the installation servlets to fix cloning. * Fix to pkispawn to correctly overwrite the pki_issuing_ca when configuring with an external CA. This resolves an issue reported by IPA in BZ #986901. * Numerous fixes to resolve build issues on F19 and RHEL. == Detailed Changes since Dogtag 10.0.3 == akoneru (1): #645 Display the admin p12 file location in the installation summary alee (6): #680 Missing apache-commons-cli dependency #665 cloning is broken for second instance in shared subsystems BZ #973224 - resteasy-base must be split into subpackages -- Add build dependency on systemd to fix build failures on f19. -- Modify pkispawn to handle case where no subsystem certs are generated -- Modify java-tools startup scripts to use correct JNI path awnuk (1): BZ #961522 - Allow key to be exported. cfu (1): BZ #971561 - server-side key generation causes NullPointerException if a parameter is not supplied by the caller (TPS) edewata (6) #582 Man page for pki-upgrade #583 Automatic backup and rollback on upgrade BZ #986901 - Fix confguration issues with external CA. BZ #985111 - token authentication problem on rhel -- Removing JNI_JAR_DIR from /etc/pki/pki.conf. -- Fixed library paths for RHEL. mharmsen (2): BZ #986506 - exclude pki-kra, pki-ocsp and pki-tks from rhel BZ #975939 - RHCS 8.1: "END CERTIFICATE" tag is not on it's own line From akoneru at redhat.com Fri Jul 26 20:13:29 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Fri, 26 Jul 2013 16:13:29 -0400 (EDT) Subject: [Pki-devel] [PATCH] 71 Patch for ticket 316- Adding pylint to the build process In-Reply-To: <1374859567.2341.63.camel@aleeredhat.laptop> References: <1374543179.31615.14.camel@akoneru.redhat.com> <1374859567.2341.63.camel@aleeredhat.laptop> Message-ID: <1564373522.3509493.1374869609685.JavaMail.root@redhat.com> A few questions/ comments: 1. In your build, you create a pylintscan directory within the source tree under pki. I would prefer this to take place in the build area so that it does not clutter up your source tree. The pylintscan is a build artifact. -- Sure can be moved. I can delete the folder once the scan is done. since the scan actually takes place before the build. (As per answer 2 - can i still keep pylintscan in pki?) 2. Do you need to remove the directory prior to each run? -- Not required. I will remove it in the script. Will just leave the pylint-report. Is it ok to put the report in the root directory of the code tree - pki? 3. What parts of the pylintrc are not default? ie. which parts did you change? -- The disable-ids property. (Will not disable conventions [C] and refactor[R].) -- Max lines - from 80 to 100 -- Removed 'string' package from deprecated modules. -- Allowing variables to be named 'rv'. (property - good-names) -- Set property - include ids = yes. 4. I noticed that you added JSONEncoder to the pylintrc as a class for which private members should not be checked. Does that allow you to eliminate the comment to # pylint: disable-msg=E0202 in encoder.py? -- Forgot to squash a few final changes made to pylintrc. it was actually not included in pylintrc. 5. Can you explain the rationale for ignoring W0511 and W0105? W0105 (pointless-string-statement): String statement has no effect Used when a string is used as a statement (which of course has no effect). This is a particular case of W0104 with its own message so you can easily disable it if you?re # using those strings as documentation, instead of comments. W0511 (fixme): Used when a warning note as FIXME or XXX is detected. -- Will add the same to the comments for disabled ids. 6. I would prefer to not ignore Convention, refactor etc. and to have these show up in the pylint reports. Based on the return code for pylint, you can have the build fail only if the bits for errors and warnings are set. -- Can be done. will make the change. 7. The pylint command line seems to have all the python executables listed -- is this required? It means having to update this list every time an executable is added, which is a step that can easily be missed. Can you just point the scan to the top level directory? -- Yes. Did not notice that Endi added __init__.py in all directories. Will change that. 8. Similarly to the point above, is there a way to scan the source tree to find all the python code? -- Yes it can be done. But since the number of source files is very small, i used this approach of copying the directories directly instead of scanning all the code. On Mon, 2013-07-22 at 21:32 -0400, Abhishek Koneru wrote: > Please review the patch which adds a script and also the pylint > configuration file to the code tree. The script is called in the compose > script for core packages before the actual packaging is done. If any > errors or warnings are reported by pylint, the build fails. > > I did not add pylint as part of build-requires in the spec file for > pki-core, but have put a check in the script to bypass trying to scan if > pylint is not installed but with a comment stating the same in the log. > > --Abhishek > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From akoneru at redhat.com Mon Jul 29 15:56:39 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 29 Jul 2013 11:56:39 -0400 Subject: [Pki-devel] [PATCH] 71-2 Patch for ticket 316- Adding pylint to the build process In-Reply-To: <1564373522.3509493.1374869609685.JavaMail.root@redhat.com> References: <1374543179.31615.14.camel@akoneru.redhat.com> <1374859567.2341.63.camel@aleeredhat.laptop> <1564373522.3509493.1374869609685.JavaMail.root@redhat.com> Message-ID: <1375113399.11374.2.camel@akoneru.redhat.com> PFA the patch which addressed all comments mentioned below. Raised a ticket for question number 8. --Abhishek On Fri, 2013-07-26 at 16:13 -0400, Abhishek Koneru wrote: > A few questions/ comments: > > 1. In your build, you create a pylintscan directory within the source > tree under pki. I would prefer this to take place in the build area so > that it does not clutter up your source tree. The pylintscan is a build > artifact. > > -- Sure can be moved. I can delete the folder once the scan is done. since the scan actually takes place before > the build. (As per answer 2 - can i still keep pylintscan in pki?) > > 2. Do you need to remove the directory prior to each run? > > -- Not required. I will remove it in the script. Will just leave the pylint-report. > Is it ok to put the report in the root directory of the code tree - pki? > > 3. What parts of the pylintrc are not default? ie. which parts did you > change? > > -- The disable-ids property. (Will not disable conventions [C] and refactor[R].) > -- Max lines - from 80 to 100 > -- Removed 'string' package from deprecated modules. > -- Allowing variables to be named 'rv'. (property - good-names) > -- Set property - include ids = yes. > > 4. I noticed that you added JSONEncoder to the pylintrc as a class for > which private members should not be checked. Does that allow you to > eliminate the comment to # pylint: disable-msg=E0202 in encoder.py? > > -- Forgot to squash a few final changes made to pylintrc. it was actually not included in pylintrc. > > 5. Can you explain the rationale for ignoring W0511 and W0105? > W0105 (pointless-string-statement): > String statement has no effect Used when a string is used as a statement (which of course has no effect). This is a particular case of W0104 with its own message so you can easily disable it if you?re # using those strings as documentation, instead of comments. > W0511 (fixme): Used when a warning note as FIXME or XXX is detected. > > -- Will add the same to the comments for disabled ids. > > 6. I would prefer to not ignore Convention, refactor etc. and to have > these show up in the pylint reports. Based on the return code for > pylint, you can have the build fail only if the bits for errors and > warnings are set. > > -- Can be done. will make the change. > > 7. The pylint command line seems to have all the python executables > listed -- is this required? It means having to update this list every > time an executable is added, which is a step that can easily be missed. > Can you just point the scan to the top level directory? > > -- Yes. Did not notice that Endi added __init__.py in all directories. Will change that. > > 8. Similarly to the point above, is there a way to scan the source tree > to find all the python code? > > -- Yes it can be done. But since the number of source files is very small, i used this approach of copying > the directories directly instead of scanning all the code. > > On Mon, 2013-07-22 at 21:32 -0400, Abhishek Koneru wrote: > > Please review the patch which adds a script and also the pylint > > configuration file to the code tree. The script is called in the compose > > script for core packages before the actual packaging is done. If any > > errors or warnings are reported by pylint, the build fails. > > > > I did not add pylint as part of build-requires in the spec file for > > pki-core, but have put a check in the script to bypass trying to scan if > > pylint is not installed but with a comment stating the same in the log. > > > > --Abhishek > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0071-2-Adding-pylint-scan-to-the-build.patch Type: text/x-patch Size: 12467 bytes Desc: not available URL: From alee at redhat.com Mon Jul 29 17:16:58 2013 From: alee at redhat.com (Ade Lee) Date: Mon, 29 Jul 2013 13:16:58 -0400 Subject: [Pki-devel] [PATCH] misc fixes for Profile REST API and CLI Message-ID: <1375118218.2341.85.camel@aleeredhat.laptop> Fix various issues with Profile Interface 1. Fixed REST API as per review. 2. Add output for profile-show and profile-find Please review, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0137-Fix-various-issues-with-Profile-Interface.patch Type: text/x-patch Size: 13262 bytes Desc: not available URL: From edewata at redhat.com Mon Jul 29 19:44:49 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 29 Jul 2013 14:44:49 -0500 Subject: [Pki-devel] [PATCH] 278 Storing authentication info in session. In-Reply-To: <51ED33B9.2040206@redhat.com> References: <51ED33B9.2040206@redhat.com> Message-ID: <51F6C631.7080208@redhat.com> On 7/22/2013 8:29 AM, Endi Sukma Dewata wrote: > The authenticator configuration has been modified to store the > authentication info in the session so it can be used by other servlets. > An update script has been added to update the configuration in existing > instances. > > The SSLAuthenticatorWithFalback was modified to propagate the > configuration to the actual authenticator handling the request. Moved the upgrade script to 10.0.4 folder. ACKed by Ade. Pushed to master. -- Endi S. Dewata From alee at redhat.com Tue Jul 30 03:38:17 2013 From: alee at redhat.com (Ade Lee) Date: Mon, 29 Jul 2013 23:38:17 -0400 Subject: [Pki-devel] [PATCH] 138 - Add Exceptions to Profile REST service Message-ID: <1375155497.2341.97.camel@aleeredhat.laptop> Adds exceptions to the Profile REST interface. Please review. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0138-Add-exceptions-to-Profile-REST-service.patch Type: text/x-patch Size: 9864 bytes Desc: not available URL: From edewata at redhat.com Tue Jul 30 15:37:41 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 30 Jul 2013 10:37:41 -0500 Subject: [Pki-devel] [PATCH] misc fixes for Profile REST API and CLI In-Reply-To: <1375118218.2341.85.camel@aleeredhat.laptop> References: <1375118218.2341.85.camel@aleeredhat.laptop> Message-ID: <51F7DDC5.8060309@redhat.com> On 7/29/2013 12:16 PM, Ade Lee wrote: > Fix various issues with Profile Interface > > 1. Fixed REST API as per review. > 2. Add output for profile-show and profile-find > > Please review, > Ade Some comments: 1. The URL in profile-show output is missing a '/rest': https://hostname:8443/ca/profiles/caManualRenewal 2. When calling profile-show as an agent/admin, the visibleOnly in retrieveProfile() is set to true, so it fails showing invisible profiles. if (visibleOnly && !profile.isVisible()) { throw new ProfileNotFoundException(profileId); } The visibleOnly should be set to true by default, and set to false if it's an privileged user, same thing as in listProfiles(). 3. The output labels can be simplified up a little bit: Profile ID: ... Name: ... Description: ... 4. There is a double space between "Profile ID:" and the value. 5. In general the profile URL is not needed by CLI users. It may only be useful for advanced users so it doesn't need to be displayed by default. In user-find the user URL will only appear in verbose mode. 6. This line probably can be removed since the profile ID is already displayed earlier. Profile Inputs: 7. The inputs probably can be simplified as follows: Input ID: i1 Name: Serial Number of Certificate to Renew Class: serialNumRenewInputImpl Attribute Name: serial_num Attribute Description: Serial Number of Certificate to Renew Attribute Syntax: string If there are multiple inputs they can be separated by blank lines. Same thing for outputs and policy sets. Another possibility is to use separate commands such as profile-input-find/show/add/del to manage the inputs. 8. In the XML output the profile element can be simplified as follows: ... "Profile" is more user-friendly than "ProfileData". 9. The input element can also be simplified as follows: 10. The unused code in createProfileDataInfo() can be removed. -- Endi S. Dewata From edewata at redhat.com Tue Jul 30 16:27:02 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 30 Jul 2013 11:27:02 -0500 Subject: [Pki-devel] [PATCH] 138 - Add Exceptions to Profile REST service In-Reply-To: <1375155497.2341.97.camel@aleeredhat.laptop> References: <1375155497.2341.97.camel@aleeredhat.laptop> Message-ID: <51F7E956.7080903@redhat.com> On 7/29/2013 10:38 PM, Ade Lee wrote: > Adds exceptions to the Profile REST interface. > > Please review. > Thanks, > Ade Just one thing, the error message is logged into debug log using CMS.debug(message), but the stack trace is displayed on standard output using e.printStackTrace(). Should we use CMS.debug(e) too? Other than that, ACK. -- Endi S. Dewata From edewata at redhat.com Tue Jul 30 17:21:41 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 30 Jul 2013 12:21:41 -0500 Subject: [Pki-devel] [PATCH] Enabled debug log for Tomcat-based TPS. Message-ID: <51F7F625.30203@redhat.com> The CS.cfg for Tomcat-based TPS has been modified to enable debug log. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0280-Enabled-debug-log-for-Tomcat-based-TPS.patch Type: text/x-patch Size: 1035 bytes Desc: not available URL: From mharmsen at redhat.com Wed Jul 31 00:29:28 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 30 Jul 2013 17:29:28 -0700 Subject: [Pki-devel] [PATCH] Bugzilla Bug #979559 - Parameter --ca_domain_url should be optional Message-ID: <51F85A68.5010900@redhat.com> Please review the attached patch for the following bug: * *Bugzilla Bug #979559* -Parameter --ca_domain_url should be optional This bug addresses the problem of attempting to configure an instance using a version of pki-silent which contains the new code with expanded parameters while using an old template from a previous version of pki-silent which did not contain these parameters. Tested by installing and successfully configuring a CA using the newly patched code with an old template which excluded the "-ca_domain_url" parameter. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Index: base/silent/src/tks/ConfigureTKS.java =================================================================== --- base/silent/src/tks/ConfigureTKS.java (revision 2625) +++ base/silent/src/tks/ConfigureTKS.java (working copy) @@ -1121,7 +1121,7 @@ x_subsystem_name); parser.addOption ( - "-ca_domain_url %s #URL to CA used to Issue Certificates for TKS Instance Creation", + "-ca_domain_url %s #URL to CA used to Issue Certificates for TKS Instance Creation (optional but recommended for IP Port Separation)", x_ca_domain_url); parser.addOption( @@ -1209,7 +1209,7 @@ subsystem_name = x_subsystem_name.value ; tks_audit_signing_cert_subject_name = x_tks_audit_signing_cert_subject_name.value; - ca_domain_url = x_ca_domain_url.value; + ca_domain_url = set_default(x_ca_domain_url.value, "empty"); boolean st = ca.ConfigureTKSInstance(); Index: base/silent/src/drm/ConfigureDRM.java =================================================================== --- base/silent/src/drm/ConfigureDRM.java (revision 2625) +++ base/silent/src/drm/ConfigureDRM.java (working copy) @@ -1298,7 +1298,7 @@ x_subsystem_name); parser.addOption ( - "-ca_domain_url %s #URL to CA used to Issue Certificates for DRM Instance Creation", + "-ca_domain_url %s #URL to CA used to Issue Certificates for DRM Instance Creation (optional but recommended for IP Port Separation)", x_ca_domain_url); parser.addOption( @@ -1407,7 +1407,7 @@ subsystem_name = x_subsystem_name.value; - ca_domain_url = x_ca_domain_url.value; + ca_domain_url = set_default(x_ca_domain_url.value, "empty"); if ((x_clone.value != null) && (x_clone.value.equalsIgnoreCase("true"))) { clone = true; Index: base/silent/src/ra/ConfigureRA.java =================================================================== --- base/silent/src/ra/ConfigureRA.java (revision 2625) +++ base/silent/src/ra/ConfigureRA.java (working copy) @@ -802,6 +802,14 @@ return true; } + private static String set_default(String val, String def) { + if ((val == null) || (val.equals(""))) { + return def; + } else { + return val; + } + } + public static void main(String args[]) { ConfigureRA ca = new ConfigureRA(); @@ -947,11 +955,11 @@ x_subsystem_name); parser.addOption ( - "-ca_issuance_url %s #URL to CA used to Issue Certificates", + "-ca_issuance_url %s #URL to CA used to Issue Certificates (optional but recommended if used with IP Port Separated CA)", x_ca_issuance_url); parser.addOption ( - "-ca_domain_url %s #URL to CA used to Issue Certificates for RA Instance Creation", + "-ca_domain_url %s #URL to CA used to Issue Certificates for RA Instance Creation (optional but recommended if used with IP Port Separated CA)", x_ca_domain_url); // and then match the arguments @@ -1012,9 +1020,9 @@ subsystem_name = x_subsystem_name.value ; - ca_issuance_url = x_ca_issuance_url.value; + ca_issuance_url = set_default(x_ca_issuance_url.value, "empty"); - ca_domain_url = x_ca_domain_url.value; + ca_domain_url = set_default(x_ca_domain_url.value, "empty"); Index: base/silent/src/ca/ConfigureCA.java =================================================================== --- base/silent/src/ca/ConfigureCA.java (revision 2625) +++ base/silent/src/ca/ConfigureCA.java (working copy) @@ -1652,7 +1652,7 @@ x_subsystem_name); parser.addOption ( - "-ca_domain_url %s #URL to CA used to Issue Certificates for CA Instance Creation", + "-ca_domain_url %s #URL to CA used to Issue Certificates for CA Instance Creation (optional but recommended for IP Port Separation)", x_ca_domain_url); parser.addOption("-external %s #Subordinate to external CA [true,false] (optional, default false)", @@ -1763,7 +1763,7 @@ subsystem_name = x_subsystem_name.value; - ca_domain_url = x_ca_domain_url.value; + ca_domain_url = set_default(x_ca_domain_url.value, "empty"); external_ca = set_default(x_external_ca.value, "false"); ext_ca_cert_file = x_ext_ca_cert_file.value; Index: base/silent/src/ocsp/ConfigureOCSP.java =================================================================== --- base/silent/src/ocsp/ConfigureOCSP.java (revision 2625) +++ base/silent/src/ocsp/ConfigureOCSP.java (working copy) @@ -1170,7 +1170,7 @@ x_subsystem_name); parser.addOption ( - "-ca_domain_url %s #URL to CA used to Issue Certificates for OCSP Instance Creation", + "-ca_domain_url %s #URL to CA used to Issue Certificates for OCSP Instance Creation (optional but recommended for IP Port Separation)", x_ca_domain_url); parser.addOption( @@ -1268,7 +1268,7 @@ subsystem_name = x_subsystem_name.value ; - ca_domain_url = x_ca_domain_url.value; + ca_domain_url = set_default(x_ca_domain_url.value, "empty"); boolean st = ca.ConfigureOCSPInstance(); Index: base/silent/src/tps/ConfigureTPS.java =================================================================== --- base/silent/src/tps/ConfigureTPS.java (revision 2625) +++ base/silent/src/tps/ConfigureTPS.java (working copy) @@ -81,11 +81,15 @@ public static String drm_agent_hostname = null; public static String drm_agent_port = null; + public static String drm_hostname = null; + public static String drm_ssl_port = null; public static String drm_admin_hostname = null; public static String drm_admin_port = null; public static String tks_agent_hostname = null; public static String tks_agent_port = null; + public static String tks_hostname = null; + public static String tks_ssl_port = null; public static String tks_admin_hostname = null; public static String tks_admin_port = null; @@ -389,27 +393,43 @@ sleep_time(); // TKS choice panel + // + // Use the following precedence: + // + // (1) tks_url set to tks_key_management_url, or + // (2) tks_url set to tks_agent_host and tks_agent_port, or + // (3) original query_string (no tks_url) + // String tks_url = null; if ( ( tks_key_management_url != null ) && ( !tks_key_management_url.equals( "" ) ) && ( !tks_key_management_url.equals( "empty" ) ) ) { tks_url = tks_key_management_url; - } else { + } else if ( ( tks_agent_hostname != null ) && + ( !tks_agent_hostname.equals( "" ) ) && + ( !tks_agent_hostname.equals( "empty" ) ) ) { // Use the TKS Agent hostname and the TKS Agent port tks_url = "https://" + tks_agent_hostname + ":" + tks_agent_port; } - System.out.println("SubsystemPanel() tks_url='" + - tks_url + "'."); - query_string = "p=7" + - "&urls=" + - URLEncoder.encode(tks_url) + - "&adminhost=" + - URLEncoder.encode(tks_admin_hostname) + - "&adminport=" + - tks_admin_port + - "&op=next" + - "&xml=true" ; + if ( tks_url != null ) { + System.out.println("SubsystemPanel() tks_url='" + + tks_url + "'."); + query_string = "p=7" + + "&urls=" + + URLEncoder.encode(tks_url) + + "&adminhost=" + + URLEncoder.encode(tks_admin_hostname) + + "&adminport=" + + tks_admin_port + + "&op=next" + + "&xml=true" ; + } else { + query_string = "p=7" + + "&urls=0" + + "&op=next" + + "&xml=true" ; + } hr = hc.sslConnect(cs_hostname,cs_port,wizard_uri,query_string); // parse xml @@ -425,28 +445,44 @@ ss_keygen = "keygen"; } + // Use the following precedence: + // + // (1) drm_url set to drm_server_side_keygen_url, or + // (2) drm_url set to drm_agent_host and drm_agent_port, or + // (3) original query_string (no drm_url) + // String drm_url = null; if ( ( drm_server_side_keygen_url != null ) && ( !drm_server_side_keygen_url.equals( "" ) ) && ( !drm_server_side_keygen_url.equals( "empty" ) ) ) { drm_url = drm_server_side_keygen_url; - } else { + } else if ( ( drm_agent_hostname != null ) && + ( !drm_agent_hostname.equals( "" ) ) && + ( !drm_agent_hostname.equals( "empty" ) ) ) { // Use the DRM Agent hostname and the DRM Agent port drm_url = "https://" + drm_agent_hostname + ":" + drm_agent_port; } - System.out.println("SubsystemPanel() drm_url='" + - drm_url + "'."); - query_string = "p=8" + - "&choice=" + ss_keygen + - "&urls=" + - URLEncoder.encode(drm_url) + - "&adminhost=" + - URLEncoder.encode(drm_admin_hostname) + - "&adminport=" + - drm_admin_port + - "&op=next" + - "&xml=true" ; + if ( drm_url != null ) { + System.out.println("SubsystemPanel() drm_url='" + + drm_url + "'."); + query_string = "p=8" + + "&choice=" + ss_keygen + + "&urls=" + + URLEncoder.encode(drm_url) + + "&adminhost=" + + URLEncoder.encode(drm_admin_hostname) + + "&adminport=" + + drm_admin_port + + "&op=next" + + "&xml=true" ; + } else { + query_string = "p=8" + + "&choice=" + ss_keygen + + "&urls=0" + + "&op=next" + + "&xml=true" ; + } hr = hc.sslConnect(cs_hostname,cs_port,wizard_uri,query_string); // parse xml @@ -999,6 +1035,14 @@ return true; } + private static String set_default(String val, String def) { + if ((val == null) || (val.equals(""))) { + return def; + } else { + return val; + } + } + public static void main(String args[]) { ConfigureTPS ca = new ConfigureTPS(); @@ -1023,11 +1067,15 @@ StringHolder x_drm_agent_hostname = new StringHolder(); StringHolder x_drm_agent_port = new StringHolder(); + StringHolder x_drm_hostname = new StringHolder(); + StringHolder x_drm_ssl_port = new StringHolder(); StringHolder x_drm_admin_hostname = new StringHolder(); StringHolder x_drm_admin_port = new StringHolder(); StringHolder x_tks_agent_hostname = new StringHolder(); StringHolder x_tks_agent_port = new StringHolder(); + StringHolder x_tks_hostname = new StringHolder(); + StringHolder x_tks_ssl_port = new StringHolder(); StringHolder x_tks_admin_hostname = new StringHolder(); StringHolder x_tks_admin_port = new StringHolder(); @@ -1136,24 +1184,32 @@ parser.addOption ("-ca_admin_port %s #CA SSL Admin port", x_ca_admin_port); - parser.addOption ("-drm_agent_hostname %s #DRM Agent Hostname", + parser.addOption ("-drm_agent_hostname %s #DRM Agent Hostname (optional but recommended if used with IP Port Separated DRM)", x_drm_agent_hostname); - parser.addOption ("-drm_agent_port %s #DRM Agent SSL port", + parser.addOption ("-drm_agent_port %s #DRM Agent SSL port (optional but recommended if used with IP Port Separated DRM)", x_drm_agent_port); + parser.addOption ("-drm_hostname %s #DRM Hostname (unused & deprecated - replaced by optional '-drm_agent_hostname')", + x_drm_hostname); + parser.addOption ("-drm_ssl_port %s #DRM SSL port (unused & deprecated - replaced by optional '-drm_agent_port')", + x_drm_ssl_port); parser.addOption ("-ss_keygen %s #Enable Server Side Keygen [true,false]", x_ss_keygen); - parser.addOption ("-drm_admin_hostname %s #DRM Admin Hostname", + parser.addOption ("-drm_admin_hostname %s #DRM Admin Hostname (optional but recommended if used with IP Port Separated DRM)", x_drm_admin_hostname); - parser.addOption ("-drm_admin_port %s #DRM SSL Admin port", + parser.addOption ("-drm_admin_port %s #DRM SSL Admin port (optional but recommended if used with IP Port Separated DRM)", x_drm_admin_port); - parser.addOption ("-tks_agent_hostname %s #TKS Agent Hostname", + parser.addOption ("-tks_agent_hostname %s #TKS Agent Hostname (optional but recommended if used with IP Port Separated TKS)", x_tks_agent_hostname); - parser.addOption ("-tks_agent_port %s #TKS Agent SSL port", + parser.addOption ("-tks_agent_port %s #TKS Agent SSL port (optional but recommended if used with IP Port Separated TKS)", x_tks_agent_port); - parser.addOption ("-tks_admin_hostname %s #TKS Admin Hostname", + parser.addOption ("-tks_hostname %s #TKS Agent Hostname (unused & deprecated - replaced by optional '-tks_agent_hostname')", + x_tks_hostname); + parser.addOption ("-tks_ssl_port %s #TKS Agent SSL port (unused & deprecated - replaced by optional '-tks_agent_port')", + x_tks_ssl_port); + parser.addOption ("-tks_admin_hostname %s #TKS Admin Hostname (optional but recommended if used with IP Port Separated TKS)", x_tks_admin_hostname); - parser.addOption ("-tks_admin_port %s #TKS SSL Admin port", + parser.addOption ("-tks_admin_port %s #TKS SSL Admin port (optional but recommended if used with IP Port Separated TKS)", x_tks_admin_port); parser.addOption ("-client_certdb_dir %s #Client CertDB dir", @@ -1245,7 +1301,7 @@ x_subsystem_name); parser.addOption ( - "-ca_issuance_url %s #URL to CA used to Issue Certificates", + "-ca_issuance_url %s #URL to CA used to Issue Certificates (optional but recommended if used with IP Port Separated CA", x_ca_issuance_url); parser.addOption ( @@ -1257,7 +1313,7 @@ x_drm_server_side_keygen_url); parser.addOption ( - "-ca_domain_url %s #URL to CA used to Issue Certificates for TPS Instance Creation", + "-ca_domain_url %s #URL to CA used to Issue Certificates for TPS Instance Creation (optional but recommended if used with IP Port Separated CA)", x_ca_domain_url); @@ -1291,15 +1347,19 @@ ca_ssl_port = x_ca_ssl_port.value; ca_admin_port = x_ca_admin_port.value; - tks_agent_hostname = x_tks_agent_hostname.value; - tks_agent_port = x_tks_agent_port.value; - tks_admin_hostname = x_tks_admin_hostname.value; - tks_admin_port = x_tks_admin_port.value; + tks_agent_hostname = set_default(x_tks_agent_hostname.value, "empty"); + tks_agent_port = set_default(x_tks_agent_port.value, "13443"); + tks_hostname = set_default(x_tks_hostname.value, tks_agent_hostname); + tks_ssl_port = set_default(x_tks_ssl_port.value, tks_agent_port); + tks_admin_hostname = set_default(x_tks_admin_hostname.value, "empty"); + tks_admin_port = set_default(x_tks_admin_port.value, "13445"); - drm_agent_hostname = x_drm_agent_hostname.value; - drm_agent_port = x_drm_agent_port.value; - drm_admin_hostname = x_drm_admin_hostname.value; - drm_admin_port = x_drm_admin_port.value; + drm_agent_hostname = set_default(x_drm_agent_hostname.value, "empty"); + drm_agent_port = set_default(x_drm_agent_port.value, "10443"); + drm_hostname = set_default(x_drm_hostname.value, drm_agent_hostname); + drm_ssl_port = set_default(x_drm_ssl_port.value, drm_agent_port); + drm_admin_hostname = set_default(x_drm_admin_hostname.value, "empty"); + drm_admin_port = set_default(x_drm_admin_port.value, "10445"); client_certdb_dir = x_client_certdb_dir.value; client_token_name = x_client_token_name.value; @@ -1358,13 +1418,13 @@ subsystem_name = x_subsystem_name.value ; - ca_issuance_url = x_ca_issuance_url.value; + ca_issuance_url = set_default(x_ca_issuance_url.value, "empty"); - tks_key_management_url = x_tks_key_management_url.value; + tks_key_management_url = set_default(x_tks_key_management_url.value, "empty"); - drm_server_side_keygen_url = x_drm_server_side_keygen_url.value; + drm_server_side_keygen_url = set_default(x_drm_server_side_keygen_url.value, "empty"); - ca_domain_url = x_ca_domain_url.value; + ca_domain_url = set_default(x_ca_domain_url.value, "empty"); Index: base/silent/src/subca/ConfigureSubCA.java =================================================================== --- base/silent/src/subca/ConfigureSubCA.java (revision 2625) +++ base/silent/src/subca/ConfigureSubCA.java (working copy) @@ -1219,7 +1219,7 @@ x_subsystem_name); parser.addOption ( - "-ca_domain_url %s #URL to CA used to Issue Certificates for SubCA Instance Creation", + "-ca_domain_url %s #URL to CA used to Issue Certificates for SubCA Instance Creation (optional but recommended for IP Port Separation)", x_ca_domain_url); parser.addOption ( @@ -1326,7 +1326,7 @@ backup_pwd = x_backup_pwd.value; subsystem_name = x_subsystem_name.value; - ca_domain_url = x_ca_domain_url.value; + ca_domain_url = set_default(x_ca_domain_url.value, "empty"); subca_sign_cert_subject_name = x_subca_sign_cert_subject_name.value ; subca_subsystem_cert_subject_name = From alee at redhat.com Wed Jul 31 14:36:37 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 31 Jul 2013 10:36:37 -0400 Subject: [Pki-devel] [PATCH] Enabled debug log for Tomcat-based TPS. In-Reply-To: <51F7F625.30203@redhat.com> References: <51F7F625.30203@redhat.com> Message-ID: <1375281397.2341.98.camel@aleeredhat.laptop> ACK On Tue, 2013-07-30 at 12:21 -0500, Endi Sukma Dewata wrote: > The CS.cfg for Tomcat-based TPS has been modified to enable debug log. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Jul 31 17:42:00 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 31 Jul 2013 13:42:00 -0400 Subject: [Pki-devel] [PATCH] misc fixes for Profile REST API and CLI In-Reply-To: <51F7DDC5.8060309@redhat.com> References: <1375118218.2341.85.camel@aleeredhat.laptop> <51F7DDC5.8060309@redhat.com> Message-ID: <1375292520.2341.100.camel@aleeredhat.laptop> Fixed in attached patch. Apply on top of previous patches. (137 and 138). Ade On Tue, 2013-07-30 at 10:37 -0500, Endi Sukma Dewata wrote: > On 7/29/2013 12:16 PM, Ade Lee wrote: > > Fix various issues with Profile Interface > > > > 1. Fixed REST API as per review. > > 2. Add output for profile-show and profile-find > > > > Please review, > > Ade > > Some comments: > > 1. The URL in profile-show output is missing a '/rest': > > https://hostname:8443/ca/profiles/caManualRenewal > > 2. When calling profile-show as an agent/admin, the visibleOnly in > retrieveProfile() is set to true, so it fails showing invisible profiles. > > if (visibleOnly && !profile.isVisible()) { > throw new ProfileNotFoundException(profileId); > } > > The visibleOnly should be set to true by default, and set to false if > it's an privileged user, same thing as in listProfiles(). > > 3. The output labels can be simplified up a little bit: > > Profile ID: ... > Name: ... > Description: ... > > 4. There is a double space between "Profile ID:" and the value. > > 5. In general the profile URL is not needed by CLI users. It may only be > useful for advanced users so it doesn't need to be displayed by default. > In user-find the user URL will only appear in verbose mode. > > 6. This line probably can be removed since the profile ID is already > displayed earlier. > > Profile Inputs: > > 7. The inputs probably can be simplified as follows: > > Input ID: i1 > Name: Serial Number of Certificate to Renew > Class: serialNumRenewInputImpl > Attribute Name: serial_num > Attribute Description: Serial Number of Certificate to Renew > Attribute Syntax: string > > If there are multiple inputs they can be separated by blank lines. Same > thing for outputs and policy sets. > > Another possibility is to use separate commands such as > profile-input-find/show/add/del to manage the inputs. > > 8. In the XML output the profile element can be simplified as follows: > > > ... > > > "Profile" is more user-friendly than "ProfileData". > > 9. The input element can also be simplified as follows: > > > > > > > 10. The unused code in createProfileDataInfo() can be removed. > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0139-Fixes-for-profile-REST-interface-from-code-review.patch Type: text/x-patch Size: 20419 bytes Desc: not available URL: From edewata at redhat.com Wed Jul 31 18:30:48 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 31 Jul 2013 13:30:48 -0500 Subject: [Pki-devel] [PATCH] 281 Added skeleton for token services. Message-ID: <51F957D8.5060808@redhat.com> A skeleton for token service and the clients has been added. Currently it's storing the database in memory. The actual implementation using LDAP database will be added after the TPS configuration code is ready. Ticket #652 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0281-Added-skeleton-for-token-services.patch Type: text/x-patch Size: 70996 bytes Desc: not available URL: From alee at redhat.com Wed Jul 31 19:54:47 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 31 Jul 2013 15:54:47 -0400 Subject: [Pki-devel] [PATCH] misc fixes for Profile REST API and CLI In-Reply-To: <1375292520.2341.100.camel@aleeredhat.laptop> References: <1375118218.2341.85.camel@aleeredhat.laptop> <51F7DDC5.8060309@redhat.com> <1375292520.2341.100.camel@aleeredhat.laptop> Message-ID: <1375300487.2341.101.camel@aleeredhat.laptop> Revised patch with more fixes .. Ade On Wed, 2013-07-31 at 13:42 -0400, Ade Lee wrote: > Fixed in attached patch. Apply on top of previous patches. > (137 and 138). > > Ade > > On Tue, 2013-07-30 at 10:37 -0500, Endi Sukma Dewata wrote: > > On 7/29/2013 12:16 PM, Ade Lee wrote: > > > Fix various issues with Profile Interface > > > > > > 1. Fixed REST API as per review. > > > 2. Add output for profile-show and profile-find > > > > > > Please review, > > > Ade > > > > Some comments: > > > > 1. The URL in profile-show output is missing a '/rest': > > > > https://hostname:8443/ca/profiles/caManualRenewal > > > > 2. When calling profile-show as an agent/admin, the visibleOnly in > > retrieveProfile() is set to true, so it fails showing invisible profiles. > > > > if (visibleOnly && !profile.isVisible()) { > > throw new ProfileNotFoundException(profileId); > > } > > > > The visibleOnly should be set to true by default, and set to false if > > it's an privileged user, same thing as in listProfiles(). > > > > 3. The output labels can be simplified up a little bit: > > > > Profile ID: ... > > Name: ... > > Description: ... > > > > 4. There is a double space between "Profile ID:" and the value. > > > > 5. In general the profile URL is not needed by CLI users. It may only be > > useful for advanced users so it doesn't need to be displayed by default. > > In user-find the user URL will only appear in verbose mode. > > > > 6. This line probably can be removed since the profile ID is already > > displayed earlier. > > > > Profile Inputs: > > > > 7. The inputs probably can be simplified as follows: > > > > Input ID: i1 > > Name: Serial Number of Certificate to Renew > > Class: serialNumRenewInputImpl > > Attribute Name: serial_num > > Attribute Description: Serial Number of Certificate to Renew > > Attribute Syntax: string > > > > If there are multiple inputs they can be separated by blank lines. Same > > thing for outputs and policy sets. > > > > Another possibility is to use separate commands such as > > profile-input-find/show/add/del to manage the inputs. > > > > 8. In the XML output the profile element can be simplified as follows: > > > > > > ... > > > > > > "Profile" is more user-friendly than "ProfileData". > > > > 9. The input element can also be simplified as follows: > > > > > > > > > > > > > > 10. The unused code in createProfileDataInfo() can be removed. > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0139-1-Fixes-for-profile-REST-interface-from-code-review.patch Type: text/x-patch Size: 22499 bytes Desc: not available URL: From alee at redhat.com Wed Jul 31 19:59:00 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 31 Jul 2013 15:59:00 -0400 Subject: [Pki-devel] [PATCH] Back port proxy port logic to 8.1 In-Reply-To: <1374723487.30744.16.camel@aleeredhat.laptop> References: <1374723487.30744.16.camel@aleeredhat.laptop> Message-ID: <1375300740.2341.102.camel@aleeredhat.laptop> After reviews, acked by Matt and pushed to 8.1 and 8.1-errata branches. On Wed, 2013-07-24 at 23:38 -0400, Ade Lee wrote: > We need to back port the proxy port configuration to RHCS 8.1. > This addresses https://bugzilla.redhat.com/show_bug.cgi?id=988189 > > This is different from the original fix in that we allow the > specification of different ports for each interface. > > Please review. > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Jul 31 20:43:38 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 31 Jul 2013 16:43:38 -0400 Subject: [Pki-devel] [PATCH] 71-2 Patch for ticket 316- Adding pylint to the build process In-Reply-To: <1375113399.11374.2.camel@akoneru.redhat.com> References: <1374543179.31615.14.camel@akoneru.redhat.com> <1374859567.2341.63.camel@aleeredhat.laptop> <1564373522.3509493.1374869609685.JavaMail.root@redhat.com> <1375113399.11374.2.camel@akoneru.redhat.com> Message-ID: <1375303418.2341.110.camel@aleeredhat.laptop> 1. There is a super long line in the compose script. Please break that into multiple lines. + echo -e "If the reported issues are false positives, please mark them ignored \nin the configuration file '$PKI_PWD/$PKI_DIR/dogtag.pylintrc' \nand build again." 2. The logic for determining whether or not to stop the script based on the return value is incorrect. +#OUTPUT STATUS CODE +# Pylint should leave with following status code: +# * 0 if everything went fine +# * 1 if a fatal message was issued +# * 2 if an error message was issued +# * 4 if a warning message was issued +# * 8 if a refactor message was issued +# * 16 if a convention message was issued +# * 32 on usage error +# +# status 1 to 16 will be bit-ORed so you can know which different categories has been issued by analysing pylint output status code + +result=0 +if [ $(($status&1)) -eq 1 ] || [ $(($status&2)) -eq 2 ] || [ $(($status&4)) -eq 4 ] +then + result=1 +fi what happens if there is an error and a warning? Then the return value will be 6. You need to decompose the error status and determine which bits were set. Ade On Mon, 2013-07-29 at 11:56 -0400, Abhishek Koneru wrote: > PFA the patch which addressed all comments mentioned below. > Raised a ticket for question number 8. > > --Abhishek > > On Fri, 2013-07-26 at 16:13 -0400, Abhishek Koneru wrote: > > A few questions/ comments: > > > > 1. In your build, you create a pylintscan directory within the source > > tree under pki. I would prefer this to take place in the build area so > > that it does not clutter up your source tree. The pylintscan is a build > > artifact. > > > > -- Sure can be moved. I can delete the folder once the scan is done. since the scan actually takes place before > > the build. (As per answer 2 - can i still keep pylintscan in pki?) > > > > 2. Do you need to remove the directory prior to each run? > > > > -- Not required. I will remove it in the script. Will just leave the pylint-report. > > Is it ok to put the report in the root directory of the code tree - pki? > > > > 3. What parts of the pylintrc are not default? ie. which parts did you > > change? > > > > -- The disable-ids property. (Will not disable conventions [C] and refactor[R].) > > -- Max lines - from 80 to 100 > > -- Removed 'string' package from deprecated modules. > > -- Allowing variables to be named 'rv'. (property - good-names) > > -- Set property - include ids = yes. > > > > 4. I noticed that you added JSONEncoder to the pylintrc as a class for > > which private members should not be checked. Does that allow you to > > eliminate the comment to # pylint: disable-msg=E0202 in encoder.py? > > > > -- Forgot to squash a few final changes made to pylintrc. it was actually not included in pylintrc. > > > > 5. Can you explain the rationale for ignoring W0511 and W0105? > > W0105 (pointless-string-statement): > > String statement has no effect Used when a string is used as a statement (which of course has no effect). This is a particular case of W0104 with its own message so you can easily disable it if you?re # using those strings as documentation, instead of comments. > > W0511 (fixme): Used when a warning note as FIXME or XXX is detected. > > > > -- Will add the same to the comments for disabled ids. > > > > 6. I would prefer to not ignore Convention, refactor etc. and to have > > these show up in the pylint reports. Based on the return code for > > pylint, you can have the build fail only if the bits for errors and > > warnings are set. > > > > -- Can be done. will make the change. > > > > 7. The pylint command line seems to have all the python executables > > listed -- is this required? It means having to update this list every > > time an executable is added, which is a step that can easily be missed. > > Can you just point the scan to the top level directory? > > > > -- Yes. Did not notice that Endi added __init__.py in all directories. Will change that. > > > > 8. Similarly to the point above, is there a way to scan the source tree > > to find all the python code? > > > > -- Yes it can be done. But since the number of source files is very small, i used this approach of copying > > the directories directly instead of scanning all the code. > > > > On Mon, 2013-07-22 at 21:32 -0400, Abhishek Koneru wrote: > > > Please review the patch which adds a script and also the pylint > > > configuration file to the code tree. The script is called in the compose > > > script for core packages before the actual packaging is done. If any > > > errors or warnings are reported by pylint, the build fails. > > > > > > I did not add pylint as part of build-requires in the spec file for > > > pki-core, but have put a check in the script to bypass trying to scan if > > > pylint is not installed but with a comment stating the same in the log. > > > > > > --Abhishek > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > From alee at redhat.com Wed Jul 31 20:59:12 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 31 Jul 2013 16:59:12 -0400 Subject: [Pki-devel] [PATCH] misc fixes for Profile REST API and CLI In-Reply-To: <1375300487.2341.101.camel@aleeredhat.laptop> References: <1375118218.2341.85.camel@aleeredhat.laptop> <51F7DDC5.8060309@redhat.com> <1375292520.2341.100.camel@aleeredhat.laptop> <1375300487.2341.101.camel@aleeredhat.laptop> Message-ID: <1375304352.2341.111.camel@aleeredhat.laptop> acked by endi. pushed to master. On Wed, 2013-07-31 at 15:54 -0400, Ade Lee wrote: > Revised patch with more fixes .. > > Ade > > On Wed, 2013-07-31 at 13:42 -0400, Ade Lee wrote: > > Fixed in attached patch. Apply on top of previous patches. > > (137 and 138). > > > > Ade > > > > On Tue, 2013-07-30 at 10:37 -0500, Endi Sukma Dewata wrote: > > > On 7/29/2013 12:16 PM, Ade Lee wrote: > > > > Fix various issues with Profile Interface > > > > > > > > 1. Fixed REST API as per review. > > > > 2. Add output for profile-show and profile-find > > > > > > > > Please review, > > > > Ade > > > > > > Some comments: > > > > > > 1. The URL in profile-show output is missing a '/rest': > > > > > > https://hostname:8443/ca/profiles/caManualRenewal > > > > > > 2. When calling profile-show as an agent/admin, the visibleOnly in > > > retrieveProfile() is set to true, so it fails showing invisible profiles. > > > > > > if (visibleOnly && !profile.isVisible()) { > > > throw new ProfileNotFoundException(profileId); > > > } > > > > > > The visibleOnly should be set to true by default, and set to false if > > > it's an privileged user, same thing as in listProfiles(). > > > > > > 3. The output labels can be simplified up a little bit: > > > > > > Profile ID: ... > > > Name: ... > > > Description: ... > > > > > > 4. There is a double space between "Profile ID:" and the value. > > > > > > 5. In general the profile URL is not needed by CLI users. It may only be > > > useful for advanced users so it doesn't need to be displayed by default. > > > In user-find the user URL will only appear in verbose mode. > > > > > > 6. This line probably can be removed since the profile ID is already > > > displayed earlier. > > > > > > Profile Inputs: > > > > > > 7. The inputs probably can be simplified as follows: > > > > > > Input ID: i1 > > > Name: Serial Number of Certificate to Renew > > > Class: serialNumRenewInputImpl > > > Attribute Name: serial_num > > > Attribute Description: Serial Number of Certificate to Renew > > > Attribute Syntax: string > > > > > > If there are multiple inputs they can be separated by blank lines. Same > > > thing for outputs and policy sets. > > > > > > Another possibility is to use separate commands such as > > > profile-input-find/show/add/del to manage the inputs. > > > > > > 8. In the XML output the profile element can be simplified as follows: > > > > > > > > > ... > > > > > > > > > "Profile" is more user-friendly than "ProfileData". > > > > > > 9. The input element can also be simplified as follows: > > > > > > > > > > > > > > > > > > > > > 10. The unused code in createProfileDataInfo() can be removed. > > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Jul 31 21:00:06 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 31 Jul 2013 17:00:06 -0400 Subject: [Pki-devel] [PATCH] 138 - Add Exceptions to Profile REST service In-Reply-To: <51F7E956.7080903@redhat.com> References: <1375155497.2341.97.camel@aleeredhat.laptop> <51F7E956.7080903@redhat.com> Message-ID: <1375304406.2341.112.camel@aleeredhat.laptop> acked by endi. Pushed to master. On Tue, 2013-07-30 at 11:27 -0500, Endi Sukma Dewata wrote: > On 7/29/2013 10:38 PM, Ade Lee wrote: > > Adds exceptions to the Profile REST interface. > > > > Please review. > > Thanks, > > Ade > > Just one thing, the error message is logged into debug log using > CMS.debug(message), but the stack trace is displayed on standard output > using e.printStackTrace(). Should we use CMS.debug(e) too? > > Other than that, ACK. > From edewata at redhat.com Wed Jul 31 21:36:07 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 31 Jul 2013 16:36:07 -0500 Subject: [Pki-devel] [PATCH] 282 Reorganized PKIRealm class. Message-ID: <51F98347.2080104@redhat.com> PKIRealm has been moved from pki-cmscore into pki-cms package because it's needed by CMSStartServlet which is in the pki-cms package. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0282-Reorganized-PKIRealm-class.patch Type: text/x-patch Size: 2348 bytes Desc: not available URL: