bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Gitbox missing tags (was: Re: [jira] [Commented] (BVAL-176) setAccessible handling is broken for multithreaded apps with SecurityManager)
Date Sun, 09 Jun 2019 17:50:28 GMT
Infra said we should do it ourselves so will try git-svn to import back our
tags, sounds long with the almost 2m of commits on svn, even on a subpath :s

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 4 juin 2019 à 19:27, Romain Manni-Bucau <rmannibucau@gmail.com> a
écrit :

> FYI: https://issues.apache.org/jira/browse/INFRA-18565
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le lun. 3 juin 2019 à 08:51, Romain Manni-Bucau <rmannibucau@gmail.com> a
> écrit :
>
>> Hello everyone,
>>
>> Do you know where are our 1.x tags/branches? Lost in svn migration?
>> Should we ask infra?
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> ---------- Forwarded message ---------
>> De : Tomasz Wysocki (JIRA) <jira@apache.org>
>> Date: lun. 3 juin 2019 à 08:48
>> Subject: [jira] [Commented] (BVAL-176) setAccessible handling is broken
>> for multithreaded apps with SecurityManager
>> To: <dev@bval.apache.org>
>>
>>
>>
>>     [
>> https://issues.apache.org/jira/browse/BVAL-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854274#comment-16854274
>> ]
>>
>> Tomasz Wysocki commented on BVAL-176:
>> -------------------------------------
>>
>> I would be grateful for 1.1.x maintenance branch (fabb6c4) and prompt
>> release of 1.1.3 to avoid custom version.
>>
>> I will do a master fix shortly (second PR).
>>
>>
>>
>> > setAccessible handling is broken for multithreaded apps with
>> SecurityManager
>> >
>> ----------------------------------------------------------------------------
>> >
>> >                 Key: BVAL-176
>> >                 URL: https://issues.apache.org/jira/browse/BVAL-176
>> >             Project: BVal
>> >          Issue Type: Bug
>> >    Affects Versions: 1.1.2, 2.0.0
>> >            Reporter: Tomasz Wysocki
>> >            Priority: Major
>> >             Fix For: 1.1.3
>> >
>> >         Attachments: ReflectionAccessibilityTest.java
>> >
>> >          Time Spent: 10m
>> >  Remaining Estimate: 0h
>> >
>> > Currently when using security manager field/method accessible flag will
>> be reset back to false.
>> > This does not work for multithreaded apps due to lack of
>> synchronization between threads.
>> > The effect is exception while validating due to invalid access to
>> protected or private members of target object.
>> > Workaround is to make all validated members public or synchronize on
>> Validator instance.
>> > This issue contains a test case to show the effect when security
>> manager is installed and there is no synchronization as well as a patch to
>> 1.1.2.
>> > This issue applies to bval2 as well but I haven't made a patch.
>> > Below is proposed resolution:
>> > Remove reseting of accessible flag when security manager is present
>> >
>> > And rationale:
>> >      This feature will not work without some synchronization on the
>> >      reflection data itself in multithreaded environment.
>> >
>> >      Therefore the feature has been removed due to following concerns:
>> >
>> >      1. resetting accessible flag for security manager does not mean
>> that for
>> >      short period of time the flag is not actually set and bad code
>> could
>> >      exploit that - therefore resetting accesible back is not really
>> making
>> >      it unaccessible to other code - this is design flaw. If accessible
>> flag
>> >      would be per thread it would work much better.
>> >
>> >      2. since accessible flag is global it would require
>> synchronization to make it work correctly,
>> >       which is costly. Current implementation just breaks for SM
>> present case
>> >      - it throws 'inaccessible' exceptions since it does not
>> synchronize at
>> >      all.
>> >
>> >      3. there is no saying what would need to be synchronized (probably
>> the
>> >      field or method reflected instances but it is not specified).
>> Therefore
>> >      synchronizing it would work only within scope of a single framework
>> >      (bval).
>> >
>> >      4. other frameworks typically don't reset back accessible and just
>> keep
>> >      the flag set. Therefore any synchronization mechanism specific to
>> bval would not cooperate
>> >      nicely or at all with other frameworks (like spring for instance).
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v7.6.3#76005)
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message