[JBoss JIRA] (WFWIP-288) JWT signed by 1024 bit long key is rejected
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFWIP-288?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFWIP-288:
-----------------------------------
Priority: Major (was: Blocker)
> JWT signed by 1024 bit long key is rejected
> -------------------------------------------
>
> Key: WFWIP-288
> URL: https://issues.redhat.com/browse/WFWIP-288
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Major
>
> According to MP-JWT 1.1 specification, 1024 and 2048 bit key sizes must be supported. Though when there is JWT signed by 1024 bit long key presented to the server, it is rejected and client receives "Unauthorized" (code 401) message.
> See chapter 9.2. Supported Public Key Formats:
> {quote}
> Support for RSA Public Keys of 1024 or 2048 bits in length is required. Other key sizes are allowed, but should be considered vendor-specific.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-296) JWT signed by 1024 bit long key is rejected
by Darran Lofthouse (Jira)
Darran Lofthouse created WFWIP-296:
--------------------------------------
Summary: JWT signed by 1024 bit long key is rejected
Key: WFWIP-296
URL: https://issues.redhat.com/browse/WFWIP-296
Project: WildFly WIP
Issue Type: Bug
Components: MP JWT
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
According to MP-JWT 1.1 specification, 1024 and 2048 bit key sizes must be supported. Though when there is JWT signed by 1024 bit long key presented to the server, it is rejected and client receives "Unauthorized" (code 401) message.
See chapter 9.2. Supported Public Key Formats:
{quote}
Support for RSA Public Keys of 1024 or 2048 bits in length is required. Other key sizes are allowed, but should be considered vendor-specific.
{quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12951) JWT signed by 1024 bit long key is rejected
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-12951?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFWIP-296 to WFLY-12951:
-----------------------------------------------
Project: WildFly (was: WildFly WIP)
Key: WFLY-12951 (was: WFWIP-296)
Component/s: MP JWT
(was: MP JWT)
> JWT signed by 1024 bit long key is rejected
> -------------------------------------------
>
> Key: WFLY-12951
> URL: https://issues.redhat.com/browse/WFLY-12951
> Project: WildFly
> Issue Type: Bug
> Components: MP JWT
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
>
> According to MP-JWT 1.1 specification, 1024 and 2048 bit key sizes must be supported. Though when there is JWT signed by 1024 bit long key presented to the server, it is rejected and client receives "Unauthorized" (code 401) message.
> See chapter 9.2. Supported Public Key Formats:
> {quote}
> Support for RSA Public Keys of 1024 or 2048 bits in length is required. Other key sizes are allowed, but should be considered vendor-specific.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2218) New payload interface
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2218?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2218.
----------------------------
Resolution: Done
> New payload interface
> ---------------------
>
> Key: JGRP-2218
> URL: https://issues.redhat.com/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0
>
> Attachments: jgrp-2218.jfr, master.jfr
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Payload}} interface which can have multiple implementations.
> h3. Reason
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectPayload}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
> h3. Design
> Instead of copying, the application creates an instance of {{Payload}} and sets the payload in {{Message}}. The {{Payload}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of payload implementations, e.g.
> * {{ByteArrayPayload}}: wraps a byte[] array with an offset and length
> * {{NioDirectPayload}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapPayload}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositePayload}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntPayload}}: a single integer
> * {{ObjectPayload}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in payloads and they're only marshalled at the end (transport).
> * {{PartialPayload}}: a ref to a {{Payload}}, with an offset and length
> * {{InputStreamPayload}}: has a ref to an input stream and copies data from input- to output stream when marshalling
> The {{Payload}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying payload
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each payload impl has an ID and it should be possible to register new impls. A {{PayloadFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Payload}}, the ID is written first, followed by the payload's {{writeTo()}} method. When reading payloads, the {{PayloadFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialPayload}} which maintains an offset and length over an underlying payload. When marshalling a {{PartialPayload}}, only the part between offset and offset+length is written to the output stream.
> For fragmentation, method {{size()}} is crucial to determine whether a payload needs to be fragmented, or not. If, for example, a payload (e.g. an {{ObjectPayload}}) cannot determine the correct size, it may return {{-1}}. This leads to the {{ObjectPayload}} getting marshalled right away and getting wrapped into a {{ByteArrayPayload}}. So if {{size()}} cannot be determined, we have exactly the same behavior as what's currently done.
> h4. Reference counting
> If we implement ref-counting, then payloads can be reused as soon as the ref-count is 0. For example, when sending a message, the payload's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the payload cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the payload cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Payload factory
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{PayloadFactory}} component for a new buffer. A naive implementation might create a new buffer every time, but a more sophisticated one might use a pool of payloads.
> The {{PayloadFactory}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of payloads: thus the creation of buffers by the application and of payloads received over the network can be controlled by the same payload management impl.
> h4. Symmetry
> When sending a {{CompositePayload}} of a 500 byte {{ByteArrayPayload}} and a 1000 byte {{NioDirectPayload}}, would we want to also get the same {{CompositePayload}} consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?
> h4. ObjectPayload
> If ObjectPayload cannot determine the size of the serialized data, it should return {{-1}}. This means that {{Message.setPayload(ObjectPayload)}} would right away serialize {{ObjectPayload}} into {{ByteArrayPayload}}.
> This means we do have the {{byte[]}} array creation (same as now), but for object payloads which do implement {{size()}} correctly, we could still do late serialization.
> h5. ObjectPayload and fragmentation
> {{FRAG3}} could decorate {{ObjectPayload}} with a fragmentation payload, which generates fragments on serialization and sends them down the stack.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4918) Update Springboot and Springframework to 2.2.2 and 5.2.2 as kieparent
by Massimiliano Dessi (Jira)
Massimiliano Dessi created DROOLS-4918:
------------------------------------------
Summary: Update Springboot and Springframework to 2.2.2 and 5.2.2 as kieparent
Key: DROOLS-4918
URL: https://issues.redhat.com/browse/DROOLS-4918
Project: Drools
Issue Type: Task
Reporter: Massimiliano Dessi
Assignee: Massimiliano Dessi
The springboot module of hacep refuse to start with the error
2020-01-09 15:30:27.085 ERROR 10 --- [ main] o.s.boot.SpringApplication : Application run failed
org.springframework.core.annotation.AnnotationConfigurationException: Attribute 'proxyBeanMethods' in annotation [org.springframework.boot.autoconfigure.SpringBootApplication] is declared as an @AliasFor nonexistent attribute 'proxyBeanMethods' in annotation [org.springframework.context.annotation.Configuration].; nested exception is java.lang.NoSuchMethodException: org.springframework.context.annotation.Configuration.proxyBeanMethods()
at org.springframework.core.annotation.AnnotationUtils$AliasDescriptor.<init>(AnnotationUtils.java:2180)
currently it use 2.1.1 and spring 5.1.3 the proxyBeanMethods was introduced in springboot 2.2
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2218) New payload interface
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2218?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2218 at 1/9/20 10:51 AM:
---------------------------------------------------------
If we created different message *types* rather than payloads, we could have the *same* memory footprint for byte[] array based messages as what we have now! E.g.
{code:java}
public abstract class Message {
protected Address dest_addr, src_addr;
protected volatile Header[] headers;
protected volatile short flags;
protected volatile byte transient_flags;
}
{code}
{code:java}
public class ByteArrayMessage extends Message {
protected int offset, length;
protected byte[] payload;
}
{code}
There could be other types of messages, e.g. {{ObjectMessage}} (equivalent to {{ObjectPayload}}), {{CompositeMessage}} and so on, but the {{ByteArrayMessage}} as sketched out above would have *exactly the same memory footprint (40 bytes)* as the current {{Message}} on {{master}}!
Perhaps people could create their own {{message}} subclasses (or implementations if {{Message}} were an interface!) and register them with a factory. The message concept is similar to what JMS provides.
was (Author: belaban):
If we created different message types rather than payloads, we could have the *same* memory footprint for byte[] array based messages as what we have now! E.g.
{code:java}
public abstract class Message {
protected Address dest_addr, src_addr;
protected volatile Header[] headers;
protected volatile short flags;
protected volatile byte transient_flags;
}
{code}
{code:java}
public class ByteArrayMessage extends Message {
protected int offset, length;
protected byte[] payload;
}
{code}
There could be other types of messages, e.g. {{ObjectMessage}} (equivalent to {{ObjectPayload}}), {{CompositeMessage}} and so on, but the {{ByteArrayMessage}} as sketched out above would have *exactly the same memory footprint (40 bytes)* as the current {{Message}} on {{master}}!
Perhaps people could create their own {{message}} subclasses (or implementations if {{Message}} were an interface!) and register them with a factory. The message concept is similar to what JMS provides.
> New payload interface
> ---------------------
>
> Key: JGRP-2218
> URL: https://issues.redhat.com/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0
>
> Attachments: jgrp-2218.jfr, master.jfr
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Payload}} interface which can have multiple implementations.
> h3. Reason
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectPayload}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
> h3. Design
> Instead of copying, the application creates an instance of {{Payload}} and sets the payload in {{Message}}. The {{Payload}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of payload implementations, e.g.
> * {{ByteArrayPayload}}: wraps a byte[] array with an offset and length
> * {{NioDirectPayload}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapPayload}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositePayload}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntPayload}}: a single integer
> * {{ObjectPayload}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in payloads and they're only marshalled at the end (transport).
> * {{PartialPayload}}: a ref to a {{Payload}}, with an offset and length
> * {{InputStreamPayload}}: has a ref to an input stream and copies data from input- to output stream when marshalling
> The {{Payload}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying payload
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each payload impl has an ID and it should be possible to register new impls. A {{PayloadFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Payload}}, the ID is written first, followed by the payload's {{writeTo()}} method. When reading payloads, the {{PayloadFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialPayload}} which maintains an offset and length over an underlying payload. When marshalling a {{PartialPayload}}, only the part between offset and offset+length is written to the output stream.
> For fragmentation, method {{size()}} is crucial to determine whether a payload needs to be fragmented, or not. If, for example, a payload (e.g. an {{ObjectPayload}}) cannot determine the correct size, it may return {{-1}}. This leads to the {{ObjectPayload}} getting marshalled right away and getting wrapped into a {{ByteArrayPayload}}. So if {{size()}} cannot be determined, we have exactly the same behavior as what's currently done.
> h4. Reference counting
> If we implement ref-counting, then payloads can be reused as soon as the ref-count is 0. For example, when sending a message, the payload's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the payload cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the payload cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Payload factory
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{PayloadFactory}} component for a new buffer. A naive implementation might create a new buffer every time, but a more sophisticated one might use a pool of payloads.
> The {{PayloadFactory}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of payloads: thus the creation of buffers by the application and of payloads received over the network can be controlled by the same payload management impl.
> h4. Symmetry
> When sending a {{CompositePayload}} of a 500 byte {{ByteArrayPayload}} and a 1000 byte {{NioDirectPayload}}, would we want to also get the same {{CompositePayload}} consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?
> h4. ObjectPayload
> If ObjectPayload cannot determine the size of the serialized data, it should return {{-1}}. This means that {{Message.setPayload(ObjectPayload)}} would right away serialize {{ObjectPayload}} into {{ByteArrayPayload}}.
> This means we do have the {{byte[]}} array creation (same as now), but for object payloads which do implement {{size()}} correctly, we could still do late serialization.
> h5. ObjectPayload and fragmentation
> {{FRAG3}} could decorate {{ObjectPayload}} with a fragmentation payload, which generates fragments on serialization and sends them down the stack.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFWIP-294:
----------------------------------------
I have just tried updating my quickstart project and I can not reproduce, here is the branch I am testing: -
https://github.com/darranl/microprofile-jwt/tree/jwks
The following command builds the project and deploys to WildFly: -
mvn install wildfly:deploy
The following command generates a token: -
mvn exec:java -Dexec.mainClass=org.wildfly.quickstarts.mpjwt.TokenUtil -Dexec.classpathScope=test -Dexec.args="testUser 2017-09-15 Echoer Subscriber"
Then the final command is used for the call but with the full token added: -
curl -H "Authorization: Bearer eyJ...59g" http://localhost:8080/microprofile-jwt/rest/secured/hello
> JWT is rejected if signature matching public key is not first in JWK set
> ------------------------------------------------------------------------
>
> Key: WFWIP-294
> URL: https://issues.redhat.com/browse/WFWIP-294
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: jwks.json, jwt.base64
>
>
> When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
> Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-288) JWT signed by 1024 bit long key is rejected
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-288?page=com.atlassian.jira.plugin... ]
Jan Kasik commented on WFWIP-288:
---------------------------------
[~dlofthouse] Thank you, as you said in this case it seems like an issue in the specification. I suggest to lower the priority and clone this to WFLY/WFCORE issue to make a tracking issue on our side. We should also document this inconsistency in specification later in the product so I will create JBEAP documentation issue linking this clone. WDYT?
> JWT signed by 1024 bit long key is rejected
> -------------------------------------------
>
> Key: WFWIP-288
> URL: https://issues.redhat.com/browse/WFWIP-288
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> According to MP-JWT 1.1 specification, 1024 and 2048 bit key sizes must be supported. Though when there is JWT signed by 1024 bit long key presented to the server, it is rejected and client receives "Unauthorized" (code 401) message.
> See chapter 9.2. Supported Public Key Formats:
> {quote}
> Support for RSA Public Keys of 1024 or 2048 bits in length is required. Other key sizes are allowed, but should be considered vendor-specific.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2400) FRAG4: cache marshalled output with FragmentedMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2400?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2400:
---------------------------
Fix Version/s: 5.1
(was: 5.0)
> FRAG4: cache marshalled output with FragmentedMessage
> -----------------------------------------------------
>
> Key: JGRP-2400
> URL: https://issues.redhat.com/browse/JGRP-2400
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> FRAG4 marshals a long message (that has *no array*) into smaller fragments, e.g. when frag_size==200, a 500 byte message is marshalled into 3 FragmentedMessages of sizes 200, 200 and 100.
> The first FragmentedMessage marshals the entire original message, but only writes the first 200 bytes to the output stream.
> The second FragmentedMessage also marshals the entire original message, and writes the second 200 bytes.
> The third message writes only the last 100 bytes.
> This means that the original message is marshalled 3 times.
> It might be faster to create an object that wraps the original message *and* a byte array, which represents the marshalled object. When marshalled for the first time, the byte array is created. The second and third time, no marshalling is performed, but instead, the FragmentedMessages access the byte array directly (at the given offsets/lengths).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFWIP-294:
----------------------------------------
Checking the MP JWT spec I believe there may be some more aspects to this to double check: -
* If the JWT token contains the "kid" claim and that claim matches the kid of a JWT then only that key should be used to check the signature.
>From that I believe we may be able to imply if the token contains no "kid" then all keys should be used to find one which verifies the signature.
This may also mean that if the token contains a "kid" that doesn't match any JWK then all keys should be used to find one which verifies the signature.
> JWT is rejected if signature matching public key is not first in JWK set
> ------------------------------------------------------------------------
>
> Key: WFWIP-294
> URL: https://issues.redhat.com/browse/WFWIP-294
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: jwks.json, jwt.base64
>
>
> When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
> Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months