[wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set

Brian Stansberry brian.stansberry at redhat.com
Fri Jan 5 13:55:51 EST 2018 

Thanks, Romain!

On Thu, Jan 4, 2018 at 8:20 AM, Romain Pelisse <belaran at redhat.com> wrote:

> Hi all,
>
> I did some more digging into this issue, trying to understand why Brian
> and I are having different results - especially on the privileges
> associated to the jars. It turns out that the wildfly builds for 10,11 and
> 12 are indeed associating the proper privileges to jars ( so -rw-r--r--.),
> but the build of EAP 7.1 are creating an archive with different set of
> priviliges (-rw-rw-r--) for jars... Same thing with the directory
> privileges. The 'domain' directory produced by all 3 final version of
> Wildfly (10,11 and 12) is associated to drwxr-xr-x and not drwxrwxr-x (as
> the EAP 7 builds produces):
>
> I've a small script to check and the output clearly shows this
> discrepencies:
>
> $ ./show-privileges.sh
> Extracting archive into /tmp/tmp.Aufm1F6d2h...Done.
> -rw-r--r--. 1 rpelisse rpelisse 364930 29 janv.  2016
> /tmp/tmp.Aufm1F6d2h/wildfly-10.0.0.Final/jboss-modules.jar
> drwxr-xr-x. 5 rpelisse rpelisse 100 29 janv.  2016
> /tmp/tmp.Aufm1F6d2h/wildfly-10.0.0.Final/domain/
> Done.
> $ export ZIP_FILE=jboss-eap-7.1.zip
> $ ./show-privileges.sh
> Extracting archive into /tmp/tmp.sErv7wRwoS...Done.
> -rw-rw-r--. 1 rpelisse rpelisse 401354  8 nov.  20:47
> /tmp/tmp.sErv7wRwoS/jboss-eap-7.1/jboss-modules.jar
> drwxrwxr-x. 5 rpelisse rpelisse 100  8 nov.  20:47
> /tmp/tmp.sErv7wRwoS/jboss-eap-7.1/domain/
> Done.
>
> I am going to investigate why EAP builds behaves differently than Wildlfy
> (but it does not really concern this mailing list). Thus, I consider this
> topic closed for upstream (at least for now, once EAP builds behavior is
> aligned with the one of Wildfly we can see if there is some more
> discrepencies to be worried about).
>
>
>
> On Tue, Dec 12, 2017 at 9:12 PM, James Perkins <jperkins at redhat.com>
> wrote:
>
>> My apologies after rereading the comment I think you're just saying
>> permissions need to be consistent across all deliverables which I agree
>> with. Sorry for the confusion.
>>
>> On Tue, Dec 12, 2017 at 8:47 AM, James Perkins <jperkins at redhat.com>
>> wrote:
>>
>>> That means the packaging tool has to know about all the files it
>>> consumes. That would make the feature pack concept irrelevant. There could
>>> be a reason the feature pack set specific permissions on a file and the
>>> provisioning tool should honor that. It shouldn't be making assumptions.
>>> Especially if that assumption is determined by a file extension.
>>>
>>> On Tue, Dec 12, 2017 at 12:20 AM, Carlo de Wolf <cdewolf at redhat.com>
>>> wrote:
>>>
>>>> If any target platform needs more restrictive permissions, those need
>>>> to apply to all deliverables (whether it is ZIP or RPMs).
>>>>
>>>> Carlo
>>>>
>>>>
>>>> On 11-12-17 23:28, James Perkins wrote:
>>>>
>>>> I personally don't have any strong opinions on what the permissions
>>>> should be. However as I said before it should definitely not be the
>>>> provisioning plugin that sets these permissions. If they need to be
>>>> different we need to change them in the feature pack.
>>>>
>>>> On Mon, Dec 11, 2017 at 4:47 AM, Romain Pelisse <belaran at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Not too much involvement except from Brian and I :) - sadly, we cannot
>>>>> move forward on this topic without a minimum of consensus. If you don't to
>>>>> participate, can you at least reply "+1 Brian" (if you think we should NOT
>>>>> try to change the current behavior") or "+1 Romain" (if you think we should
>>>>> address this issue somehow).
>>>>>
>>>>> (please don't vote on the PR I've proposed, it's just a proposal on
>>>>> HOW we could do it - here I want to assert IF we want to do it, not voting
>>>>> on the "how").
>>>>>
>>>>> On Wed, Dec 6, 2017 at 6:05 PM, Brian Stansberry <
>>>>> brian.stansberry at redhat.com> wrote:
>>>>>
>>>>>> On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Brian (and all),
>>>>>>>
>>>>>>> I honestly understand your resistance, and I'm completely fine if we
>>>>>>> end up closing this all issue as WONTDO or REJECTED. I just do want to have
>>>>>>> a discussion about it and come back with clear reasons and motivations for
>>>>>>> changing or not the privileges of each of those files.
>>>>>>>
>>>>>>
>>>>>> Thanks for doing this! There have been a number of issues filed over
>>>>>> the last year or so on this general topic so I'm very happy to see them
>>>>>> getting addressed here via the WildFly community. Most of the issues I've
>>>>>> been talking about are JBEAP issues in JIRA, which is fine, but the best
>>>>>> way to get this solid is to get WildFly the way we want it first.
>>>>>>
>>>>>> Even on the config file read perms thing I mentioned in my last post,
>>>>>> I'm personally resistant to changing it, but my biggest resistance is to
>>>>>> doing that without a full community discussion.
>>>>>>
>>>>>>
>>>>>>> Given that we see different things on our local setup, I think the
>>>>>>> best will be to use a build on a CI Server and works from what we see
>>>>>>> there. Is there an easy way for me to clone a job building Wildfly and
>>>>>>> tweak it on some (publicly) accessible instance ?
>>>>>>>
>>>>>>
>>>>>> https://developer.jboss.org/thread/224262 describes how to get a zip
>>>>>> built from a daily CI job.
>>>>>>
>>>>>> If anyone has any insights on this, please speak up!
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry <
>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>
>>>>>>>> A slightly different topic, related to the "logging.properties/xml
>>>>>>>> config file" topic is whether these files should be world and/or group
>>>>>>>> readable.
>>>>>>>>
>>>>>>>> Changing this has been proposed in the past on the EAP side,
>>>>>>>> primarily based on the argument that users could put sensitive data in
>>>>>>>> these files. This thread seems like a good time to debate this a bit in
>>>>>>>> community.
>>>>>>>>
>>>>>>>> I've resisted that primarily on the basis of:
>>>>>>>>
>>>>>>>> 1) These files or those similarly used have had these perms as far
>>>>>>>> back as I can find in JBoss AS. So the odds that some people are relying
>>>>>>>> upon those perms is fairly high and we need to assume a change would be a
>>>>>>>> breaking change for some people.
>>>>>>>>
>>>>>>>> 2) Other software I've looked at like Tomcat and httpd have similar
>>>>>>>> permission schemes to what we have for their config files, which can also
>>>>>>>> potentially include sensitive data.
>>>>>>>>
>>>>>>>> 3) We provide facilities like the vault or elytron credential store
>>>>>>>> refs for keeping sensitive data out of the config files.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry <
>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Thanks, Romain.
>>>>>>>>>
>>>>>>>>> Re: what the actual permissions are, FWIW I get what I see on both
>>>>>>>>> my macbook and my Fedora 27 machine, both when unzipping the actual
>>>>>>>>> 11.0.0.Final and when unzipping the result of a build of master, and both
>>>>>>>>> with and without the -Prelease -Pjboss-release args to maven that we
>>>>>>>>> include when doing actual releases. Unzipping the zip in build/target
>>>>>>>>> doesn't include the jars of course.
>>>>>>>>>
>>>>>>>>> So it sounds like we need input from others.
>>>>>>>>>
>>>>>>>>> Re: modules.xml, if you are seeing those as rw-r--r-- as well,
>>>>>>>>> then +1 to ignoring them in further discussion.
>>>>>>>>>
>>>>>>>>> Re: logging.properties, those serve a very similar conceptual role
>>>>>>>>> to the standalone|host|domain.xml files so I see no reason for them to have
>>>>>>>>> different perms. However, you and I are getting different results, where
>>>>>>>>> you report them as group writable and I don't. What do you see for the xml
>>>>>>>>> config files?
>>>>>>>>>
>>>>>>>>> Re: RPM changing to match WildFly, that's an EAP discussion, so
>>>>>>>>> that can be taken up elsewhere once we have WildFly the way we want it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran at redhat.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> Hi Brian and all,
>>>>>>>>>>
>>>>>>>>>> err, my own observation differs from yours. I've rebuild Wildfly
>>>>>>>>>> from the last content of the master branch and get the same privileges on
>>>>>>>>>> the jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
>>>>>>>>>> Same with the domain folder, which turns out on my local system associated
>>>>>>>>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
>>>>>>>>>> transcript of what I did - maybe you can spot why our results differs so
>>>>>>>>>> much.
>>>>>>>>>>
>>>>>>>>>> $ git show
>>>>>>>>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
>>>>>>>>>> Merge: 051f080 c7d9075
>>>>>>>>>> Author: Kabir Khan <kkhan at redhat.com>
>>>>>>>>>> Date:   Tue Nov 28 17:46:40 2017 +0000
>>>>>>>>>>
>>>>>>>>>>     Merge pull request #10669 from praxeo/WFLY-9284
>>>>>>>>>>
>>>>>>>>>>     WFLY-9284 Correct MVN env variable to mvnw.cmd
>>>>>>>>>>
>>>>>>>>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d
>>>>>>>>>> wildfly-12.zip
>>>>>>>>>> ...
>>>>>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.
>>>>>>>>>> Alpha1-SNAPSHOT/jboss-modules.jar
>>>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
>>>>>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>>>>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
>>>>>>>>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
>>>>>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>>>>>>>>>>
>>>>>>>>>> Checking all the jars in the distribution, they all appears to
>>>>>>>>>> have the mask '-rw-rw-r--':
>>>>>>>>>>
>>>>>>>>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done
>>>>>>>>>> | sed -e '/-rw-rw-r--/d'
>>>>>>>>>> $
>>>>>>>>>>
>>>>>>>>>> Regarding properties files, here is the exhaustive list of
>>>>>>>>>> properties that RPM packaging has modified the privileges of:
>>>>>>>>>>
>>>>>>>>>> appclient/configuration/logging.properties rw-------
>>>>>>>>>> domain/configuration/application-roles.properties rw-------
>>>>>>>>>> domain/configuration/default-server-logging.properties rw-------
>>>>>>>>>> domain/configuration/logging.properties rw-------
>>>>>>>>>> domain/configuration/mgmt-groups.properties rw-------
>>>>>>>>>> standalone/configuration/application-roles.properties rw-------
>>>>>>>>>> standalone/configuration/logging.properties rw-------
>>>>>>>>>> standalone/configuration/mgmt-groups.properties rw-------
>>>>>>>>>>
>>>>>>>>>> If I compare that with the content of the extract zip (same fresh
>>>>>>>>>> built as above), I can see that 4 files are not having the same mask
>>>>>>>>>> (rw------):
>>>>>>>>>>
>>>>>>>>>> $ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do
>>>>>>>>>> ls -l $file ; done
>>>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>>>>>>> appclient/configuration/logging.properties
>>>>>>>>>> -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41
>>>>>>>>>> domain/configuration/application-roles.properties
>>>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>>>>>>> domain/configuration/default-server-logging.properties
>>>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>>>>>>> domain/configuration/logging.properties
>>>>>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>>>>>>> domain/configuration/mgmt-groups.properties
>>>>>>>>>> -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
>>>>>>>>>> standalone/configuration/application-roles.properties
>>>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>>>>>>> standalone/configuration/logging.properties
>>>>>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>>>>>>> standalone/configuration/mgmt-groups.properties
>>>>>>>>>>
>>>>>>>>>> Now, as you said, those files privileges are indeed fine-grained,
>>>>>>>>>> so maybe we can push back to people making the RPM for them to NOT change
>>>>>>>>>> the following files privileges:
>>>>>>>>>>
>>>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>>>>>>> appclient/configuration/logging.properties
>>>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>>>>>>> domain/configuration/default-server-logging.properties
>>>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>>>>>>> domain/configuration/logging.properties
>>>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>>>>>>> standalone/configuration/logging.properties
>>>>>>>>>>
>>>>>>>>>> However, I don't see the value of letting those files accessible
>>>>>>>>>> either group member or any user on the system, but maybe we can make the
>>>>>>>>>> argument they should. But the write privileges for group member sounds
>>>>>>>>>> wrong to me.
>>>>>>>>>>
>>>>>>>>>> Also, I'm puzzled Brian and I are seeing different things - am I
>>>>>>>>>> looking at the correct zipfile here ?
>>>>>>>>>>
>>>>>>>>>> Note: You also mention the module.xml - as far as I can see from
>>>>>>>>>> the diff provided with issue JBEAP-12374, I don't see any issue with
>>>>>>>>>> privileges regarding those files, so we can remove them of the discussion.
>>>>>>>>>> The only changes we need to discuss is removing the 'write' privileges' for
>>>>>>>>>> the group on jars, reducing the scope of permissions on (some) folders, and
>>>>>>>>>> privileges on (some) properties files. So, module.xml are out of the scope.
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
>>>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Seems I forgot to "Reply to All" yesterday. The following was
>>>>>>>>>>> meant to be sent to wildfly-dev.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
>>>>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Before getting into the specifics, first a general note re:
>>>>>>>>>>>> perms.
>>>>>>>>>>>>
>>>>>>>>>>>> Our general permission set for is rwxr-xr-x for directories and
>>>>>>>>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up.
>>>>>>>>>>>> ;). Otherwise I think any deviation from that we should justify. Not that
>>>>>>>>>>>> deviations are wrong, just that they need to have a reason.
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <
>>>>>>>>>>>> belaran at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Well, the diff is between the RPM and the zipfile is pretty
>>>>>>>>>>>>> long, but it boils down to the 3 set of differences I've pointed out on
>>>>>>>>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    - *.properties and .jar* files are associated with the
>>>>>>>>>>>>>    mask rw-rw-r-- giving access to it to any other users and allowing group
>>>>>>>>>>>>>    member to modify the file - the RPM distribution fixes that by removing the
>>>>>>>>>>>>>    write privileges for the group (rw-r--r--). I personnaly don't see the
>>>>>>>>>>>>>    value of letting the group members modify those files, I just can see how
>>>>>>>>>>>>>    this could be exploited, so I would say it falls into "clearly wrong and
>>>>>>>>>>>>>    not our intent". A case might be made for the .properties files, but for
>>>>>>>>>>>>>    jars file I really don't see a valid use case (unless of course, any of you
>>>>>>>>>>>>>    know one) ;
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are a few different things here, so let's deal with them
>>>>>>>>>>>> separately.
>>>>>>>>>>>>
>>>>>>>>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them
>>>>>>>>>>>> as rwxr--r--. Which seems correct to me. In case I'm seeing something
>>>>>>>>>>>> wrong, I don't see why they should vary from the general standard. And the
>>>>>>>>>>>> module.xml file should be consistent, since there's not much point in
>>>>>>>>>>>> locking people from touching jars but letting them change what jars get
>>>>>>>>>>>> loaded.
>>>>>>>>>>>>
>>>>>>>>>>>> For properties files, let's consider them on a more
>>>>>>>>>>>> fine-grained basis. For example, the properties files used by the security
>>>>>>>>>>>> realms have different kinds of data than logging.properties does.
>>>>>>>>>>>>
>>>>>>>>>>>> The perms on the security realm property files are rw-------,
>>>>>>>>>>>> not rw-rw-r--.
>>>>>>>>>>>>
>>>>>>>>>>>> The logging.properties files are rw-r--r-- which is consistent
>>>>>>>>>>>> with the domain|host|standalone.xml files and with the general standard.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    -
>>>>>>>>>>>>>    - *some directories* like 'domain/tmp/auth' have too
>>>>>>>>>>>>>    restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x
>>>>>>>>>>>>>    (that I don't really agree with) and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    - *other directories*, likes 'domain' have again a too
>>>>>>>>>>>>>    permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make
>>>>>>>>>>>>>    senses.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the unzip I see these directories as rwxr-xr-x, which I
>>>>>>>>>>>> think is fine.
>>>>>>>>>>>>
>>>>>>>>>>>> Are you concerned with any other directories besides
>>>>>>>>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone?
>>>>>>>>>>>>
>>>>>>>>>>>>> So we need to find an agreement on those three items, and then
>>>>>>>>>>>>> see how we proceed to implement the fix (if needed).
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>>>>>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think we need to start with the assumption that the
>>>>>>>>>>>>>> permissions we have in the zip are the way they are for a reason and
>>>>>>>>>>>>>> evaluate possible changes based on discussion here of each type of change.
>>>>>>>>>>>>>> Maybe the RPM settings are better, maybe they are not. Or maybe they are
>>>>>>>>>>>>>> better but the improvement is not worth the disruption a change may cause
>>>>>>>>>>>>>> to our end users, who may rely on the current zip settings. Or maybe what
>>>>>>>>>>>>>> we have in the zip is clearly wrong and doesn't follow our own intent. I
>>>>>>>>>>>>>> expect we'll probably see a little of each category, although hopefully
>>>>>>>>>>>>>> some changes for WF 11 removed the "clearly wrong and doesn't follow our
>>>>>>>>>>>>>> intent" cases. :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <
>>>>>>>>>>>>>> belaran at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies
>>>>>>>>>>>>>>> between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most
>>>>>>>>>>>>>>> of those discrepancies - or the most relevant ones, are some fine tuning
>>>>>>>>>>>>>>> performed on the (POSIX) privileges (things such as removing the write
>>>>>>>>>>>>>>> privilege for member of the same group as the owner of the file).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've looked into this and because those files are produced
>>>>>>>>>>>>>>> by our own Maven plugin (as part of wildfly-build-tools), we can not simply
>>>>>>>>>>>>>>> modify the assembly.xml. Which actually is probably for the best, as it
>>>>>>>>>>>>>>> would made the assembly file quite cumbersome.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Anyhow, I've worked on a proposal[2] for the
>>>>>>>>>>>>>>> wildfly-build-tools, but when I reported the problem on WFLY-9574[3], Brian
>>>>>>>>>>>>>>> suggested I started a discussion here. So does anyone have a (strong)
>>>>>>>>>>>>>>> opinion about this issue and/or how to resolve it ? :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (For the record, I do think it is best to fix the privileges
>>>>>>>>>>>>>>> to follow what the RPM does for us for now, but if you feel this issue
>>>>>>>>>>>>>>> should not be addressed, and dev- the issue, I'm certainly not opposed to
>>>>>>>>>>>>>>> it either).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>>>>>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>>>>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Brian Stansberry
>>>>>>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>>>>>>> Red Hat
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Brian Stansberry
>>>>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>>>>> Red Hat
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Brian Stansberry
>>>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>>>> Red Hat
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Brian Stansberry
>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>> Red Hat
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Brian Stansberry
>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>> Red Hat
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Brian Stansberry
>>>>>> Manager, Senior Principal Software Engineer
>>>>>> Red Hat
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> James R. Perkins
>>>> JBoss by Red Hat
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> James R. Perkins
>>> JBoss by Red Hat
>>>
>>
>>
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180105/4f1b5be4/attachment-0001.html

More information about the wildfly-dev mailing list