[JBoss JIRA] (ELY-611) Unintentional integer overflow in LongNameSetPermissionCollection
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-611?page=com.atlassian.jira.plugin.sy... ]
David Lloyd reassigned ELY-611:
-------------------------------
Assignee: David Lloyd (was: Darran Lofthouse)
> Unintentional integer overflow in LongNameSetPermissionCollection
> -----------------------------------------------------------------
>
> Key: ELY-611
> URL: https://issues.jboss.org/browse/ELY-611
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta7
> Reporter: Ondrej Lukas
> Assignee: David Lloyd
> Labels: static_analysis
> Fix For: 1.1.0.Beta8
>
>
> There are potentially overflowing expressions in org.wildfly.security.permission.LongNameSetPermissionCollection in {{getBitsForName}} method. Expressions {{1 << nameEnumeration.size()}} and {{1 << nameEnumeration.indexOf(name)}} are evaluated as integer but assigned to {{bits}} variable which is long. It can be avoided by casting {{1}} to long.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ELY-615) Improvement for usage of file.mkdirs() in FileSystemSecurityRealm.Identity
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-615?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-615.
-----------------------------
Resolution: Rejected
This one is not a bug, but was deliberate, and the reason is that there are only three possible outcomes to this operation:
# The directory is created - in this case everything is fine
# The directory already exists - in this case everything is still fine
# The directory doesn't exist but can't be created for some reason - in this case the subsequent file operation will fail
Because 2 & 3 cannot be distinguished reliably, it's better to just defer until the filesystem operation.
> Improvement for usage of file.mkdirs() in FileSystemSecurityRealm.Identity
> --------------------------------------------------------------------------
>
> Key: ELY-615
> URL: https://issues.jboss.org/browse/ELY-615
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta7
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Minor
> Labels: static_analysis
> Fix For: 1.1.0.Beta8
>
>
> There is method {{tempPath()}} in org.wildfly.security.auth.realm.FileSystemSecurityRealm.Identity which uses {{file.mkdirs()}} without checking its return value. It is bad practice to ignore return value of this method (since false means that file has not been created and it can result to any unexpected and confusing failure later).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (DROOLS-1242) built-in accumulate functions shall ignore NULLs
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1242:
--------------------------------------
Summary: built-in accumulate functions shall ignore NULLs
Key: DROOLS-1242
URL: https://issues.jboss.org/browse/DROOLS-1242
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Priority: Optional
This is a spin-off out of another problem [here|https://issues.jboss.org/browse/GUVNOR-2589?focusedCommentId=1326892...] for a proposal of improvement.
It could actually be beneficial for built-in accumulate functions to ignore NULLs.
This would be similar behavior of other languages such:
* SQL (e.g.: MySQL, Oracle, ..)
* Clojure
Currently it is up to the rule author to put a guarding condition in the first accumulate {{<source pattern>}} to manually ignore null sources to avoid the built-in accumulate functions to ignore NULLs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (DROOLS-1242) built-in accumulate functions shall ignore NULLs
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1242?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1242:
-----------------------------------
Description:
This is a spin-off out of another problem [here|https://issues.jboss.org/browse/GUVNOR-2589?focusedCommentId=1326892...] for a proposal of improvement.
It could actually be beneficial for built-in accumulate functions to ignore NULLs.
This would be similar behavior of other languages such:
* SQL (e.g.: MySQL, Oracle, ..)
* Clojure
Currently it is up to the rule author to put a guarding condition in the first accumulate {{<source pattern>}} to manually ignore null sources to avoid the built-in accumulate functions to break trying to accumulate on NULLs.
was:
This is a spin-off out of another problem [here|https://issues.jboss.org/browse/GUVNOR-2589?focusedCommentId=1326892...] for a proposal of improvement.
It could actually be beneficial for built-in accumulate functions to ignore NULLs.
This would be similar behavior of other languages such:
* SQL (e.g.: MySQL, Oracle, ..)
* Clojure
Currently it is up to the rule author to put a guarding condition in the first accumulate {{<source pattern>}} to manually ignore null sources to avoid the built-in accumulate functions to ignore NULLs.
> built-in accumulate functions shall ignore NULLs
> ------------------------------------------------
>
> Key: DROOLS-1242
> URL: https://issues.jboss.org/browse/DROOLS-1242
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Optional
>
> This is a spin-off out of another problem [here|https://issues.jboss.org/browse/GUVNOR-2589?focusedCommentId=1326892...] for a proposal of improvement.
> It could actually be beneficial for built-in accumulate functions to ignore NULLs.
> This would be similar behavior of other languages such:
> * SQL (e.g.: MySQL, Oracle, ..)
> * Clojure
> Currently it is up to the rule author to put a guarding condition in the first accumulate {{<source pattern>}} to manually ignore null sources to avoid the built-in accumulate functions to break trying to accumulate on NULLs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFLY-6895) TimerService problem(duplicated resource)
by Artur Kowalczyk (JIRA)
[ https://issues.jboss.org/browse/WFLY-6895?page=com.atlassian.jira.plugin.... ]
Artur Kowalczyk updated WFLY-6895:
----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/9083
> TimerService problem(duplicated resource)
> -----------------------------------------
>
> Key: WFLY-6895
> URL: https://issues.jboss.org/browse/WFLY-6895
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Two standalone instances connected into a cluster.
> *Master WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=master
> {code}
> *Slave WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=slave -Djboss.socket.binding.port-offset=100
> {code}
> Both instances has the same singleton policy defined in singleton-full-ha.xml:
> {code}
> <singleton-policy name="scada-singleton" cache-container="server">
> <simple-election-policy>
> <name-preferences>master</name-preferences>
> </simple-election-policy>
> </singleton-policy>
> {code}
> Reporter: Artur Kowalczyk
> Assignee: Jason Greene
>
> I found a problem with TimerService that occurs when your application is configured as a singleton deployment.
> *Test Case*
> # Start master node, the app is also started - OK
> # Start slave node, the app is deployed but bot stared - OK
> # Stop master node, the app is started on slave - OK
> # Start master node, there is a preference for node name so the app will be started again on master and stopped in slave - OK
> # Stop master node, the app should be started again on slave but an exception occur. - ERROR
> {code}
> 09:50:42,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "wildfly-ejb-in-ear-ejb.jar" of deployment "wildfly-ejb-in-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0086: Failed to install management resources for TimerEJB
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:82)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource timer-service
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.register(DeploymentResourceSupport.java:322)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.registerDeploymentSubResource(DeploymentResourceSupport.java:219)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.installManagementResource(EjbManagementDeploymentUnitProcessor.java:119)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:79)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFLY-6895) TimerService problem(duplicated resource)
by Artur Kowalczyk (JIRA)
[ https://issues.jboss.org/browse/WFLY-6895?page=com.atlassian.jira.plugin.... ]
Artur Kowalczyk updated WFLY-6895:
----------------------------------
Issue Type: Bug (was: Feature Request)
> TimerService problem(duplicated resource)
> -----------------------------------------
>
> Key: WFLY-6895
> URL: https://issues.jboss.org/browse/WFLY-6895
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Two standalone instances connected into a cluster.
> *Master WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=master
> {code}
> *Slave WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=slave -Djboss.socket.binding.port-offset=100
> {code}
> Both instances has the same singleton policy defined in singleton-full-ha.xml:
> {code}
> <singleton-policy name="scada-singleton" cache-container="server">
> <simple-election-policy>
> <name-preferences>master</name-preferences>
> </simple-election-policy>
> </singleton-policy>
> {code}
> Reporter: Artur Kowalczyk
> Assignee: Jason Greene
>
> I found a problem with TimerService that occurs when your application is configured as a singleton deployment.
> *Test Case*
> # Start master node, the app is also started - OK
> # Start slave node, the app is deployed but bot stared - OK
> # Stop master node, the app is started on slave - OK
> # Start master node, there is a preference for node name so the app will be started again on master and stopped in slave - OK
> # Stop master node, the app should be started again on slave but an exception occur. - ERROR
> {code}
> 09:50:42,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "wildfly-ejb-in-ear-ejb.jar" of deployment "wildfly-ejb-in-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0086: Failed to install management resources for TimerEJB
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:82)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource timer-service
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.register(DeploymentResourceSupport.java:322)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.registerDeploymentSubResource(DeploymentResourceSupport.java:219)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.installManagementResource(EjbManagementDeploymentUnitProcessor.java:119)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:79)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Petr Kremensky (JIRA)
Petr Kremensky created WFCORE-1680:
--------------------------------------
Summary: Tab completion for echo-dmr command is broken
Key: WFCORE-1680
URL: https://issues.jboss.org/browse/WFCORE-1680
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Petr Kremensky
Assignee: Alexey Loubyansky
Tab completion for echo-dmr command doesn't work.
To reproduce, start the standalone server and connect with CLI
*actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
{noformat}
[standalone@localhost:9990 /] echo-dmr /sub[TAB]
core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
[standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
{noformat}
*expected*
{noformat}
[standalone@localhost:9990 /] echo-dmr /sub[TAB]
[standalone@localhost:9990 /] echo-dmr /subsystem=
[standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
[standalone@localhost:9990 /] echo-dmr /subsystem=logging
{noformat}
The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (ELY-438) There is not possibility to use alternative JSSE Cipher Suite Names for IBM JDK
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-438?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-438:
---------------------------------
Fix Version/s: 1.1.0.Beta8
(was: 1.1.0.CR1)
> There is not possibility to use alternative JSSE Cipher Suite Names for IBM JDK
> -------------------------------------------------------------------------------
>
> Key: ELY-438
> URL: https://issues.jboss.org/browse/ELY-438
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.Beta8, 1.0.3.CR1
>
>
> There is not possibility to use alternative JSSE Cipher Suite Names for IBM JDK8
> Interchange TLS prefix to SSL and vice versa is not supported.
> Here is list of standard JSSE Cipher Suite Names
> http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNa...
> In my opinion this file is mapping file for our purpose. It is?
> https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> For IBM JDK are different JSSE Cipher Suite Names (different prefix).
> Most items from this list are missing in MechanismDatabase.properties mentioned above.
> http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
> For example:
> JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* is only defined for IBM JDK.
> It is *TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA* for Oracle JDK.
> If I try start server with JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* I will get this error:
> {code}
> 16:55:25,594 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.IllegalArgumentException: ELY05017: Token "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA" not allowed at offset 33 of mechanism selection string "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA"
> at org.wildfly.security.ssl.CipherSuiteSelector.fromString(CipherSuiteSelector.java:399)
> at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:125)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 16:55:25,598 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("https-listener" => "https")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Caused by: java.lang.IllegalArgumentException: ELY05017: Token \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\" not allowed at offset 33 of mechanism selection string \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\""}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (SECURITY-943) AdvancedLdapLoginModule authentication fails when some part of DN is part of LDAP URL
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-943?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-943:
--------------------------------------
Fix Version/s: Negotiation_3_0_4_CR1
(was: Negotiation_3_0_3_Final)
> AdvancedLdapLoginModule authentication fails when some part of DN is part of LDAP URL
> -------------------------------------------------------------------------------------
>
> Key: SECURITY-943
> URL: https://issues.jboss.org/browse/SECURITY-943
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_2_Final
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: Negotiation_3_0_4_CR1
>
>
> In case when part of DN is placed in LDAP URL instead of baseCtxDN then authentication fails (see [1] for details about this URL) in AdvancedLdapLoginModule. Authentication is provided by binding with user DN and password, but in this case user DN does not include DN part from LDAP URL which leads to fail.
> Thrown exception:
> {code}
> javax.naming.AuthenticationException: LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate user uid=jduke,ou=People
> com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3135)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3081)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2883)
> com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2797)
> com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> javax.naming.InitialContext.init(InitialContext.java:244)
> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.constructLdapContext(AdvancedLdapLoginModule.java:486)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.authenticate(AdvancedLdapLoginModule.java:669)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.innerLogin(AdvancedLdapLoginModule.java:397)
> org.jboss.security.negotiation.AdvancedLdapLoginModule$AuthorizeAction.run(AdvancedLdapLoginModule.java:967)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.login(AdvancedLdapLoginModule.java:326)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> {code}
> [1] https://tools.ietf.org/html/rfc2255
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months