[jira] [Assigned] (GROOVY-9786) SC: cast exception for variable assigned within conditional blocks
[
https://issues.apache.org/jira/browse/GROOVY-9786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-9786:
---
Assignee: Eric Milles
> SC: cast exception for variable assigned within conditional blocks
> --
>
> Key: GROOVY-9786
> URL: https://issues.apache.org/jira/browse/GROOVY-9786
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.13
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
>
> Consider the following:
> {code:groovy}
> interface Zero {
> def m()
> }
> class One implements Zero {
> def m() { 'One' }
> }
> class Two implements Zero {
> def m() { 'Two' }
> }
> boolean aaa() { false }
> boolean bbb() { true }
> @groovy.transform.CompileStatic
> void test() {
> Zero x
> if (aaa()) {
> x = new One()
> } else if (bbb()) {
> x = new Two()
> }
> x.m() // GroovyCastException: Cannot cast object 'Two@654d8173' with class
> 'Two' to class 'One'
> }
> test()
> {code}
> This case was recently converted from dynamic groovy -- where it executes
> fine -- to {{@CompileStatic}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] eric-milles opened a new pull request #1408: GROOVY-9786: STC: retain explicit declared type for uninitialized variable
eric-milles opened a new pull request #1408: URL: https://github.com/apache/groovy/pull/1408 https://issues.apache.org/jira/browse/GROOVY-9786 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GROOVY-9780) stuck waiting for lock with AbstractConcurrentMap$Segment.put
[ https://issues.apache.org/jira/browse/GROOVY-9780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218587#comment-17218587 ] Boon commented on GROOVY-9780: -- The question is why ReferenceManager$1.removeStallEntries ? Is it because of some cache size related? > stuck waiting for lock with AbstractConcurrentMap$Segment.put > -- > > Key: GROOVY-9780 > URL: https://issues.apache.org/jira/browse/GROOVY-9780 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.6 >Reporter: Boon >Priority: Major > > A simple getProperty operation resulting in > org.codehaus.groovy.util.AbstractConcurrentMap$Segment.getOrPut and finally > waiting for a none existing lock for over 10 minutes (stuck thread). See > following stuck thread: > [STUCK] ExecuteThread: '4' for queue: 'weblogic.kernel.Default > (self-tuning)'" daemon prio=10 tid=0x7fcfea664000 nid=0x1d5c waiting on > condition [0x7fcf484a3000] java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) - parking to wait for > <0x00059e0e4600> (a > org.codehaus.groovy.util.ManagedConcurrentMap$Segment) at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) > at > org.codehaus.groovy.util.LockableObject.lock(LockableObject.java:37) > at > org.codehaus.groovy.util.AbstractConcurrentMapBase$Segment.removeEntry(AbstractConcurrentMapBase.java:174) > at > org.codehaus.groovy.util.ManagedConcurrentMap$Entry.finalizeReference(ManagedConcurrentMap.java:81) > at > org.codehaus.groovy.util.ManagedConcurrentMap$EntryWithValue.finalizeReference(ManagedConcurrentMap.java:115) > at > org.codehaus.groovy.util.ReferenceManager$1.removeStallEntries(ReferenceManager.java:86) > at > org.codehaus.groovy.util.ReferenceManager$1.afterReferenceCreation(ReferenceManager.java:94) > at > org.codehaus.groovy.util.ReferenceManager$2.afterReferenceCreation(ReferenceManager.java:111) > at > org.codehaus.groovy.util.ManagedReference.(ManagedReference.java:36) > at > org.codehaus.groovy.util.ManagedReference.(ManagedReference.java:40) > at > org.codehaus.groovy.util.ManagedConcurrentMap$Entry.(ManagedConcurrentMap.java:55) > at > org.codehaus.groovy.util.ManagedConcurrentMap$EntryWithValue.(ManagedConcurrentMap.java:98) > at > org.codehaus.groovy.util.ManagedConcurrentMap$Segment.createEntry(ManagedConcurrentMap.java:46) > at > org.codehaus.groovy.util.AbstractConcurrentMap$Segment.put(AbstractConcurrentMap.java:157) > at > org.codehaus.groovy.util.AbstractConcurrentMap$Segment.getOrPut(AbstractConcurrentMap.java:100) > at > org.codehaus.groovy.util.AbstractConcurrentMap.getOrPut(AbstractConcurrentMap.java:38) > at > org.codehaus.groovy.runtime.metaclass.ThreadManagedMetaBeanProperty$ThreadBoundGetter.invoke(ThreadManagedMetaBeanProperty.java:183) > at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) > at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1849) at > groovy.lang.ExpandoMetaClass.getProperty(ExpandoMetaClass.java:1155) > at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3734) at > groovy.lang.ExpandoMetaClass.getProperty(ExpandoMetaClass.java:1167) > at groovy.lang.GroovyObjectSupport.getProperty(GroovyObjectSupport.java:38) > at groovy.lang.Script.getProperty(Script.java:58) at > org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:50) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:307) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9779) Inconsistency with callable properties in static context
[
https://issues.apache.org/jira/browse/GROOVY-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218323#comment-17218323
]
Eric Milles commented on GROOVY-9779:
-
https://github.com/apache/groovy/pull/1407
> Inconsistency with callable properties in static context
>
>
> Key: GROOVY-9779
> URL: https://issues.apache.org/jira/browse/GROOVY-9779
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:title=playground.groovy}
> class C {
> def call() {
> 42
> }
> }
> class Container {
> static final staticC = new C()
> def instanceC = new C()
> }
> assert Container.staticC() == 42 // works fine
> def container = new Container()
> assert container.staticC() == 42 // MissingMethodException
> assert container.instanceC() == 42 // MissingMethodException
> {code}
> I'd expect the invocations to fail or to work in both static and instance
> contexts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] eric-milles opened a new pull request #1407: GROOVY-9779: don't chain call properties together
eric-milles opened a new pull request #1407: URL: https://github.com/apache/groovy/pull/1407 https://issues.apache.org/jira/browse/GROOVY-9779 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GROOVY-9779) Inconsistency with callable properties in static context
[
https://issues.apache.org/jira/browse/GROOVY-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218299#comment-17218299
]
Eric Milles commented on GROOVY-9779:
-
[~paulk] Could you please clone the issue for the static compile support? Then
I will take a look at that.
[~daniilo] I will look into the call property chaining mentioned above. That
was an unexpected consequence.
> Inconsistency with callable properties in static context
>
>
> Key: GROOVY-9779
> URL: https://issues.apache.org/jira/browse/GROOVY-9779
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:title=playground.groovy}
> class C {
> def call() {
> 42
> }
> }
> class Container {
> static final staticC = new C()
> def instanceC = new C()
> }
> assert Container.staticC() == 42 // works fine
> def container = new Container()
> assert container.staticC() == 42 // MissingMethodException
> assert container.instanceC() == 42 // MissingMethodException
> {code}
> I'd expect the invocations to fail or to work in both static and instance
> contexts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9779) Inconsistency with callable properties in static context
[
https://issues.apache.org/jira/browse/GROOVY-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218228#comment-17218228
]
Paul King commented on GROOVY-9779:
---
Thanks [~daniilo]. I tried an example which worked on 4 but not 3, but I can
replicate your example on both.
> Inconsistency with callable properties in static context
>
>
> Key: GROOVY-9779
> URL: https://issues.apache.org/jira/browse/GROOVY-9779
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:title=playground.groovy}
> class C {
> def call() {
> 42
> }
> }
> class Container {
> static final staticC = new C()
> def instanceC = new C()
> }
> assert Container.staticC() == 42 // works fine
> def container = new Container()
> assert container.staticC() == 42 // MissingMethodException
> assert container.instanceC() == 42 // MissingMethodException
> {code}
> I'd expect the invocations to fail or to work in both static and instance
> contexts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9779) Inconsistency with callable properties in static context
[
https://issues.apache.org/jira/browse/GROOVY-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218215#comment-17218215
]
Daniil Ovchinnikov commented on GROOVY-9779:
[~paulk] the example can be found in the body of this ticket. Adjusted with the
@CS, it looks like:
{code:title=playground.groovy}
class C {
def call() {
42
}
}
class Container {
static final staticC = new C()
def instanceC = new C()
}
@groovy.transform.CompileStatic
def usage() {
assert Container.staticC() == 42 // [Static type checking] - Cannot find
matching method Container#staticC()
def container = new Container()
assert container.staticC() == 42 // [Static type checking] - Cannot find
matching method Container#staticC()
assert container.instanceC() == 42 // [Static type checking] - Cannot find
matching method Container#instanceC()
}
usage()
{code}
> Inconsistency with callable properties in static context
>
>
> Key: GROOVY-9779
> URL: https://issues.apache.org/jira/browse/GROOVY-9779
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:title=playground.groovy}
> class C {
> def call() {
> 42
> }
> }
> class Container {
> static final staticC = new C()
> def instanceC = new C()
> }
> assert Container.staticC() == 42 // works fine
> def container = new Container()
> assert container.staticC() == 42 // MissingMethodException
> assert container.instanceC() == 42 // MissingMethodException
> {code}
> I'd expect the invocations to fail or to work in both static and instance
> contexts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9788) Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
[
https://issues.apache.org/jira/browse/GROOVY-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218194#comment-17218194
]
Paul King edited comment on GROOVY-9788 at 10/21/20, 9:09 AM:
--
Thanks for the suggestion. It should be in the next releases. I updated the
description with some further information. Let me know if that sounds like it
covers everything you had in mind.
was (Author: paulk):
Thanks for the suggestion. It should be in the next releases. I'll update the
description with some more information.
> Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
>
>
> Key: GROOVY-9788
> URL: https://issues.apache.org/jira/browse/GROOVY-9788
> Project: Groovy
> Issue Type: Dependency upgrade
>Affects Versions: 3.0.6
>Reporter: Angela Guardian
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
>
> {quote}
> As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the permissions of
> temporary files it created so that only the current user was allowed to
> access them. Unfortunately the fixcrlf task deleted the temporary file and
> created a new one without said protection, effectively nullifying the effort.
> This would still allow an attacker to inject modified source files into the
> build process.
> {quote}
> [1] [CVE
> Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
> [2] [Apache Ant Security Reports|https://ant.apache.org/security.html]
> Overall risk assessment for Groovy: *low*
> Details:
> * Groovy's internal usage of Ant is not affected by the above mentioned CVE.
> * We encourage Groovy users using Groovy in combination with Ant, e.g.
> {{AntBuilder}} to read the Apache Ant Security Report[1] and follow the
> mitigation advice. In particular, anyone using the {{fixcrlf}} Ant task
> should take note.
> * Recent Groovy versions, e.g. 3.0.6, have been built against Ant 1.10.8 but
> do not require that version and can safely be used with Ant 1.10.9 which has
> additional protections against the vulnerability mentioned in the CVE.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9788) Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
[
https://issues.apache.org/jira/browse/GROOVY-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9788:
--
Description:
{quote}
As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the permissions of
temporary files it created so that only the current user was allowed to access
them. Unfortunately the fixcrlf task deleted the temporary file and created a
new one without said protection, effectively nullifying the effort. This would
still allow an attacker to inject modified source files into the build process.
{quote}
[1] [CVE
Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
[2] [Apache Ant Security Reports|https://ant.apache.org/security.html]
Overall risk assessment for Groovy: *low*
Details:
* Groovy's internal usage of Ant is not affected by the above mentioned CVE.
* We encourage Groovy users using Groovy in combination with Ant, e.g.
{{AntBuilder}} to read the Apache Ant Security Report[1] and follow the
mitigation advice. In particular, anyone using the {{fixcrlf}} Ant task should
take note.
* Recent Groovy versions, e.g. 3.0.6, have been built against Ant 1.10.8 but do
not require that version and can safely be used with Ant 1.10.9 which has
additional protections against the vulnerability mentioned in the CVE.
was:
{quote}As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the
permissions of temporary files it created so that only the current user was
allowed to access them. Unfortunately the fixcrlf task deleted the temporary
file and created a new one without said protection, effectively nullifying the
effort. This would still allow an attacker to inject modified source files into
the build process.
{quote}
[1] [CVE
Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
[2] [Apache Ant Security Reports|https://ant.apache.org/security.html]
Overall risk assessment for Groovy: *low*
Details: Groovy's internal usage of Ant is not affected by the above mentioned
CVE. We encourage Groovy users using Groovy in combination with Ant, e.g.
AntBuilder to read the Apache Ant Security Report[1]
> Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
>
>
> Key: GROOVY-9788
> URL: https://issues.apache.org/jira/browse/GROOVY-9788
> Project: Groovy
> Issue Type: Dependency upgrade
>Affects Versions: 3.0.6
>Reporter: Angela Guardian
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
>
> {quote}
> As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the permissions of
> temporary files it created so that only the current user was allowed to
> access them. Unfortunately the fixcrlf task deleted the temporary file and
> created a new one without said protection, effectively nullifying the effort.
> This would still allow an attacker to inject modified source files into the
> build process.
> {quote}
> [1] [CVE
> Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
> [2] [Apache Ant Security Reports|https://ant.apache.org/security.html]
> Overall risk assessment for Groovy: *low*
> Details:
> * Groovy's internal usage of Ant is not affected by the above mentioned CVE.
> * We encourage Groovy users using Groovy in combination with Ant, e.g.
> {{AntBuilder}} to read the Apache Ant Security Report[1] and follow the
> mitigation advice. In particular, anyone using the {{fixcrlf}} Ant task
> should take note.
> * Recent Groovy versions, e.g. 3.0.6, have been built against Ant 1.10.8 but
> do not require that version and can safely be used with Ant 1.10.9 which has
> additional protections against the vulnerability mentioned in the CVE.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9788) Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
[
https://issues.apache.org/jira/browse/GROOVY-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9788:
--
Description:
{quote}As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the
permissions of temporary files it created so that only the current user was
allowed to access them. Unfortunately the fixcrlf task deleted the temporary
file and created a new one without said protection, effectively nullifying the
effort. This would still allow an attacker to inject modified source files into
the build process.
{quote}
[1] [CVE
Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
[2] [Apache Ant Security Reports|https://ant.apache.org/security.html]
was:
{quote}As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the
permissions of temporary files it created so that only the current user was
allowed to access them. Unfortunately the fixcrlf task deleted the temporary
file and created a new one without said protection, effectively nullifying the
effort. This would still allow an attacker to inject modified source files into
the build process.
{quote}
[Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
[Apache Ant Security Reports|https://ant.apache.org/security.html]
> Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
>
>
> Key: GROOVY-9788
> URL: https://issues.apache.org/jira/browse/GROOVY-9788
> Project: Groovy
> Issue Type: Dependency upgrade
>Affects Versions: 3.0.6
>Reporter: Angela Guardian
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
>
> {quote}As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the
> permissions of temporary files it created so that only the current user was
> allowed to access them. Unfortunately the fixcrlf task deleted the temporary
> file and created a new one without said protection, effectively nullifying
> the effort. This would still allow an attacker to inject modified source
> files into the build process.
> {quote}
> [1] [CVE
> Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
> [2] [Apache Ant Security Reports|https://ant.apache.org/security.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9788) Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
[
https://issues.apache.org/jira/browse/GROOVY-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9788:
--
Description:
{quote}As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the
permissions of temporary files it created so that only the current user was
allowed to access them. Unfortunately the fixcrlf task deleted the temporary
file and created a new one without said protection, effectively nullifying the
effort. This would still allow an attacker to inject modified source files into
the build process.
{quote}
[1] [CVE
Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
[2] [Apache Ant Security Reports|https://ant.apache.org/security.html]
Overall risk assessment for Groovy: *low*
Details: Groovy's internal usage of Ant is not affected by the above mentioned
CVE. We encourage Groovy users using Groovy in combination with Ant, e.g.
AntBuilder to read the Apache Ant Security Report[1]
was:
{quote}As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the
permissions of temporary files it created so that only the current user was
allowed to access them. Unfortunately the fixcrlf task deleted the temporary
file and created a new one without said protection, effectively nullifying the
effort. This would still allow an attacker to inject modified source files into
the build process.
{quote}
[1] [CVE
Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
[2] [Apache Ant Security Reports|https://ant.apache.org/security.html]
> Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
>
>
> Key: GROOVY-9788
> URL: https://issues.apache.org/jira/browse/GROOVY-9788
> Project: Groovy
> Issue Type: Dependency upgrade
>Affects Versions: 3.0.6
>Reporter: Angela Guardian
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
>
> {quote}As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the
> permissions of temporary files it created so that only the current user was
> allowed to access them. Unfortunately the fixcrlf task deleted the temporary
> file and created a new one without said protection, effectively nullifying
> the effort. This would still allow an attacker to inject modified source
> files into the build process.
> {quote}
> [1] [CVE
> Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
> [2] [Apache Ant Security Reports|https://ant.apache.org/security.html]
> Overall risk assessment for Groovy: *low*
> Details: Groovy's internal usage of Ant is not affected by the above
> mentioned CVE. We encourage Groovy users using Groovy in combination with
> Ant, e.g. AntBuilder to read the Apache Ant Security Report[1]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9788) Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
[
https://issues.apache.org/jira/browse/GROOVY-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-9788.
---
Fix Version/s: 4.0.0-alpha-2
3.0.7
Assignee: Paul King
Resolution: Fixed
Thanks for the suggestion. It should be in the next releases. I'll update the
description with some more information.
> Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
>
>
> Key: GROOVY-9788
> URL: https://issues.apache.org/jira/browse/GROOVY-9788
> Project: Groovy
> Issue Type: Dependency upgrade
>Affects Versions: 3.0.6
>Reporter: Angela Guardian
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
>
> {quote}As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the
> permissions of temporary files it created so that only the current user was
> allowed to access them. Unfortunately the fixcrlf task deleted the temporary
> file and created a new one without said protection, effectively nullifying
> the effort. This would still allow an attacker to inject modified source
> files into the build process.
> {quote}
> [Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
> [Apache Ant Security Reports|https://ant.apache.org/security.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9788) Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
[
https://issues.apache.org/jira/browse/GROOVY-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9788:
--
Summary: Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
(was: Bump Ant versions (fixes Apache Ant CVE 2020-11979))
> Bump Ant version to 1.10.9 (fixes Apache Ant CVE 2020-11979)
>
>
> Key: GROOVY-9788
> URL: https://issues.apache.org/jira/browse/GROOVY-9788
> Project: Groovy
> Issue Type: Dependency upgrade
>Affects Versions: 3.0.6
>Reporter: Angela Guardian
>Priority: Major
>
> {quote}As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the
> permissions of temporary files it created so that only the current user was
> allowed to access them. Unfortunately the fixcrlf task deleted the temporary
> file and created a new one without said protection, effectively nullifying
> the effort. This would still allow an attacker to inject modified source
> files into the build process.
> {quote}
> [Reference|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11979]
> [Apache Ant Security Reports|https://ant.apache.org/security.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9789) Stubbing: Mode of running Groovyc to only output stubs
[ https://issues.apache.org/jira/browse/GROOVY-9789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218184#comment-17218184 ] Paul King edited comment on GROOVY-9789 at 10/21/20, 8:25 AM: -- This is relatively easy to do programmatically but not something currently supported from the command line. For programmatic usage, you'd need something like [1], but with the phase on the referenced line changed to SEMANTIC_ANALYSIS. You'd also need to keep the stubs as per [2]. To enable this from the command line, the FileSystemCompiler would need to know about a finishing phase and the unit.compile() statements at [3] would need to be made aware of that phase. But I haven't actually tried those changes myself. [1] https://github.com/apache/groovy/blob/master/src/test/groovy/bugs/Groovy6086Bug.groovy#L63 [2] https://github.com/apache/groovy/blob/master/src/test/groovy/bugs/Groovy9031.groovy#L33 [3] https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/tools/FileSystemCompiler.java#L309-L317 You could probably also achieve something similar to the programmatic approach using ASTTest. was (Author: paulk): This is relatively easy to do programmatically but not something currently supported from the command line. For programmatic usage, you'd need something like [1], but with the phase on the referenced line changed to SEMANTIC_ANALYSIS. You'd also need to keep the stubs as per [2]. To enable this from the command line, the FileSystemCompiler would need to know about a finishing phase and the unit.compile() statements at [3] would need to be made aware of that phase. But I haven't actually tried those changes myself. [1] https://github.com/apache/groovy/blob/master/src/test/groovy/bugs/Groovy6086Bug.groovy#L63 [2] https://github.com/apache/groovy/blob/master/src/test/groovy/bugs/Groovy9031.groovy#L33 [3] https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/tools/FileSystemCompiler.java#L309-L317 > Stubbing: Mode of running Groovyc to only output stubs > -- > > Key: GROOVY-9789 > URL: https://issues.apache.org/jira/browse/GROOVY-9789 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Endre Stølsvik >Priority: Major > > So, I'd love if I could instruct groovyc to only perform the Java stubbing > part (and stop there). > The rationale for this is described in this StackOverflow question: > [https://stackoverflow.com/q/53759596/39334] > Basically, *I want to have three-way joint/mixed compilation between Java, > Groovy and Kotlin.* And I figure that if I first could get the java stubs of > all groovy files, I could manage to do this in four steps as described in the > SO question. > If this logic holds, it would probably hold for other languages too, so it > could conceivably be a nice feature to have not only for my scenario with > Java+Groovy+Kotlin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9789) Stubbing: Mode of running Groovyc to only output stubs
[ https://issues.apache.org/jira/browse/GROOVY-9789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218184#comment-17218184 ] Paul King commented on GROOVY-9789: --- This is relatively easy to do programmatically but not something currently supported from the command line. For programmatic usage, you'd need something like [1], but with the phase on the referenced line changed to SEMANTIC_ANALYSIS. You'd also need to keep the stubs as per [2]. To enable this from the command line, the FileSystemCompiler would need to know about a finishing phase and the unit.compile() statements at [3] would need to be made aware of that phase. But I haven't actually tried those changes myself. [1] https://github.com/apache/groovy/blob/master/src/test/groovy/bugs/Groovy6086Bug.groovy#L63 [2] https://github.com/apache/groovy/blob/master/src/test/groovy/bugs/Groovy9031.groovy#L33 [3] https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/tools/FileSystemCompiler.java#L309-L317 > Stubbing: Mode of running Groovyc to only output stubs > -- > > Key: GROOVY-9789 > URL: https://issues.apache.org/jira/browse/GROOVY-9789 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Endre Stølsvik >Priority: Major > > So, I'd love if I could instruct groovyc to only perform the Java stubbing > part (and stop there). > The rationale for this is described in this StackOverflow question: > [https://stackoverflow.com/q/53759596/39334] > Basically, *I want to have three-way joint/mixed compilation between Java, > Groovy and Kotlin.* And I figure that if I first could get the java stubs of > all groovy files, I could manage to do this in four steps as described in the > SO question. > If this logic holds, it would probably hold for other languages too, so it > could conceivably be a nice feature to have not only for my scenario with > Java+Groovy+Kotlin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-9789) Stubbing: Mode of running Groovyc to only output stubs
[ https://issues.apache.org/jira/browse/GROOVY-9789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Endre Stølsvik updated GROOVY-9789: --- Description: So, I'd love if I could instruct groovyc to only perform the Java stubbing part (and stop there). The rationale for this is described in this StackOverflow question: [https://stackoverflow.com/q/53759596/39334] Basically, *I want to have three-way joint/mixed compilation between Java, Groovy and Kotlin.* And I figure that if I first could get the java stubs of all groovy files, I could manage to do this in four steps as described in the SO question. If this logic holds, it would probably hold for other languages too, so it could conceivably be a nice feature to have not only for my scenario with Java+Groovy+Kotlin. was: So, I'd love if I could instruct groovyc to only perform the Java stubbing part (and stop there). The rationale for this is described in this StackOverflow question: [https://stackoverflow.com/q/53759596/39334] Basically, *I want to have three-way joint/mixed compilation between Java, Groovy and Kotlin.* And I figure that if I first could get the stubs of all groovy files, I could manage to do this in four steps as described in the SO question. If this logic holds, it would probably hold for other languages too, so it could conceivably be a nice feature to have not only for my scenario with Java+Groovy+Kotlin. > Stubbing: Mode of running Groovyc to only output stubs > -- > > Key: GROOVY-9789 > URL: https://issues.apache.org/jira/browse/GROOVY-9789 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Endre Stølsvik >Priority: Major > > So, I'd love if I could instruct groovyc to only perform the Java stubbing > part (and stop there). > The rationale for this is described in this StackOverflow question: > [https://stackoverflow.com/q/53759596/39334] > Basically, *I want to have three-way joint/mixed compilation between Java, > Groovy and Kotlin.* And I figure that if I first could get the java stubs of > all groovy files, I could manage to do this in four steps as described in the > SO question. > If this logic holds, it would probably hold for other languages too, so it > could conceivably be a nice feature to have not only for my scenario with > Java+Groovy+Kotlin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-9789) Stubbing: Mode of running Groovyc to only output stubs
[ https://issues.apache.org/jira/browse/GROOVY-9789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Endre Stølsvik updated GROOVY-9789: --- Description: So, I'd love if I could instruct groovyc to only perform the Java stubbing part (and stop there). The rationale for this is described in this StackOverflow question: [https://stackoverflow.com/q/53759596/39334] Basically, *I want to have three-way joint/mixed compilation between Java, Groovy and Kotlin.* And I figure that if I first could get the stubs of all groovy files, I could manage to do this in four steps as described in the SO question. If this logic holds, it would probably hold for other languages too, so it could conceivably be a nice feature to have not only for my scenario with Java+Groovy+Kotlin. was: So, I'd love if I could instruct groovyc to only to the Java stubbing part. The rationale for this is described in this StackOverflow question: [https://stackoverflow.com/q/53759596/39334] Basically, *I want to have three-way joint/mixed compilation between Java, Groovy and Kotlin.* And I figure that if I first could get the stubs of all groovy files, I could manage to do this in four steps as described in the SO question. If this logic holds, it would probably hold for other languages too, so it could conceivably be a nice feature to have not only for my scenario with Java+Groovy+Kotlin. > Stubbing: Mode of running Groovyc to only output stubs > -- > > Key: GROOVY-9789 > URL: https://issues.apache.org/jira/browse/GROOVY-9789 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Endre Stølsvik >Priority: Major > > So, I'd love if I could instruct groovyc to only perform the Java stubbing > part (and stop there). > The rationale for this is described in this StackOverflow question: > [https://stackoverflow.com/q/53759596/39334] > Basically, *I want to have three-way joint/mixed compilation between Java, > Groovy and Kotlin.* And I figure that if I first could get the stubs of all > groovy files, I could manage to do this in four steps as described in the SO > question. > If this logic holds, it would probably hold for other languages too, so it > could conceivably be a nice feature to have not only for my scenario with > Java+Groovy+Kotlin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-9789) Stubbing: Mode of running Groovyc to only output stubs
Endre Stølsvik created GROOVY-9789: -- Summary: Stubbing: Mode of running Groovyc to only output stubs Key: GROOVY-9789 URL: https://issues.apache.org/jira/browse/GROOVY-9789 Project: Groovy Issue Type: Improvement Components: Compiler Reporter: Endre Stølsvik So, I'd love if I could instruct groovyc to only to the Java stubbing part. The rationale for this is described in this StackOverflow question: [https://stackoverflow.com/q/53759596/39334] Basically, *I want to have three-way joint/mixed compilation between Java, Groovy and Kotlin.* And I figure that if I first could get the stubs of all groovy files, I could manage to do this in four steps as described in the SO question. If this logic holds, it would probably hold for other languages too, so it could conceivably be a nice feature to have not only for my scenario with Java+Groovy+Kotlin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
