[jira] [Comment Edited] (XERCESC-2188) Use-after-free on external DTD scan
[ https://issues.apache.org/jira/browse/XERCESC-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716851#comment-17716851 ] Ilguiz Latypov edited comment on XERCESC-2188 at 4/26/23 8:33 PM: -- Since year 2019, the NIST record of this bug included the upper boundary for the Xerces C version, 3.2.2 (probably because it was the last known version of the product). It was updated to include 3.2.3 in years 2020 (in the human-readable description) and 2022 (in the machine-readable one). https://nvd.nist.gov/vuln/detail/CVE-2018-1311#VulnChangeHistorySection Now that 3.2.4 is released, it shows as clean from the CVE despite still being vulnerable. This makes the component scan users miss the danger. Is there a way to remove the upper boundary from the CVE? I can see the change history at NIST extends to this year. Hopefully a breaking change (4.0?) can be free from the vulnerability, at which point the CVE record could add the proper upper boundary. was (Author: ilatypov): Since year 2019, the NIST record of this bug included the upper boundary for the Xerces C version, 3.2.3 (probably because it was the last known version of the product). https://nvd.nist.gov/vuln/detail/CVE-2018-1311#VulnChangeHistorySection Now that 3.2.4 is released, it shows as clean from the CVE despite still being vulnerable. This makes the component scan users miss the danger. Is there a way to remove the upper boundary from the CVE? I can see the change history at NIST extends to this year. Hopefully a breaking change (4.0?) can be free from the vulnerability, at which point the CVE record could add the proper upper boundary. > Use-after-free on external DTD scan > --- > > Key: XERCESC-2188 > URL: https://issues.apache.org/jira/browse/XERCESC-2188 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) >Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, > 3.1.4, 3.2.1, 3.2.2 >Reporter: Scott Cantor >Priority: Major > Attachments: Apache-496067-disclosure-report.pdf > > > This is a record of an unfixed bug reported in 2018 in the DTD scanner, per > the attached PDF, corresponding to CVE-2018-1311. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2188) Use-after-free on external DTD scan
[ https://issues.apache.org/jira/browse/XERCESC-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716908#comment-17716908 ] Ilguiz Latypov commented on XERCESC-2188: - Perhaps NVD and scan KBs rely on this ticket's description carrying the "affected versions" field. Adding 3.2.3 and 3.2.4 to it could at least confirm the presence of the weakness for others. NVD mentions Apache as the CVE Numbering Authority for this issue. > Use-after-free on external DTD scan > --- > > Key: XERCESC-2188 > URL: https://issues.apache.org/jira/browse/XERCESC-2188 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) >Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, > 3.1.4, 3.2.1, 3.2.2 >Reporter: Scott Cantor >Priority: Major > Attachments: Apache-496067-disclosure-report.pdf > > > This is a record of an unfixed bug reported in 2018 in the DTD scanner, per > the attached PDF, corresponding to CVE-2018-1311. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2188) Use-after-free on external DTD scan
[ https://issues.apache.org/jira/browse/XERCESC-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716851#comment-17716851 ] Ilguiz Latypov commented on XERCESC-2188: - Since year 2019, the NIST record of this bug included the upper boundary for the Xerces C version, 3.2.3 (probably because it was the last known version of the product). https://nvd.nist.gov/vuln/detail/CVE-2018-1311#VulnChangeHistorySection Now that 3.2.4 is released, it shows as clean from the CVE despite still being vulnerable. This makes the component scan users miss the danger. Is there a way to remove the upper boundary from the CVE? I can see the change history at NIST extends to this year. Hopefully a breaking change (4.0?) can be free from the vulnerability, at which point the CVE record could add the proper upper boundary. > Use-after-free on external DTD scan > --- > > Key: XERCESC-2188 > URL: https://issues.apache.org/jira/browse/XERCESC-2188 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) >Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, > 3.1.4, 3.2.1, 3.2.2 >Reporter: Scott Cantor >Priority: Major > Attachments: Apache-496067-disclosure-report.pdf > > > This is a record of an unfixed bug reported in 2018 in the DTD scanner, per > the attached PDF, corresponding to CVE-2018-1311. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Comment Edited] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
[
https://issues.apache.org/jira/browse/SLING-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989033#comment-16989033
]
Ilguiz Latypov edited comment on SLING-8879 at 1/31/20 9:24 PM:
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML
or XHTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode with {{raw u}}
* the double quotes {{raw }} against terminating the string,
* the escape character {{raw }} against breaking the context of escaping
other characters,
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} against the mandatory HTML entity decoding in
XHTML (but not HTML) documents.
was (Author: ilatypov):
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML
or XHTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode with {{raw u}}
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} against the mandatory HTML entity decoding in
XHTML (but not HTML) documents.
> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct
> for pasting into a javascript string literal
>
>
> Key: SLING-8879
> URL: https://issues.apache.org/jira/browse/SLING-8879
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
> Reporter: Ilguiz Latypov
>Priority: Minor
>
> The current implementation risks exceptions in strict javascript engines.
> |return source == null ? null :
> Encode.forJavaScript(source).replace("-", "u002D");|
> Substitutes on top of the encoder's result with the intent to correct the
> encoder are near-sighted (i.e. suffer from the context-free approach). If
> {{source}} had a backslash followed by a dash, i.e. {{raw }}, the
> {{forJavaScript}} call would properly change the backslash into 2 backslashes
> {{raw }} (this would result in the javascript engine
> turning the string literal back to {{raw }}). But the subsequent
> {{replace}} call will destroy the context of the second backslash, turning
> the string into {{raw u002D}} which would turn to {{raw
> u002D}} in the javascript engine's variable.
> I argue for dropping the {{.replace()}} call (aiming at disabling malicious
> comment injection) here and encoding the opening angle bracket {{raw <}} as
> {{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
> protect against both the malicious comment injection and the injection of
> closing script tags {{raw script>}} forcing the javascript
> interpreter to drop out of the string literal context and drop out of the
> script context.
> The existing prefixing of forward slashes with a backslash agrees with JSON
> but not with Javascript. It should be removed in favour of replacing just the
> opening angle bracket.
> {noformat}
> SingleEscapeCharacter :: one of
> ' " \ b f n r t v
> {noformat}
> [https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
> [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> I noticed that JSONObject#toString suffers from the same idea of a
> non-universal protection of the forward slash. I guess both XSSAPI and
> JSONObject#toString reuse the same code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
[
https://issues.apache.org/jira/browse/SLING-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989033#comment-16989033
]
Ilguiz Latypov edited comment on SLING-8879 at 12/5/19 6:33 PM:
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML
or XHTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode with {{raw u}}
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} against the mandatory HTML entity decoding in
XHTML (but not HTML) documents.
was (Author: ilatypov):
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML
or XHTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode with {{raw u}}
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} against the mandatory HTML entity decoding in
XHTML (but not HTML) documents. This decoding applies to text both outside and
inside the script tag.
> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct
> for pasting into a javascript string literal
>
>
> Key: SLING-8879
> URL: https://issues.apache.org/jira/browse/SLING-8879
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
> Reporter: Ilguiz Latypov
>Priority: Minor
>
> The current implementation risks exceptions in strict javascript engines.
> |return source == null ? null :
> Encode.forJavaScript(source).replace("-", "u002D");|
> Substitutes on top of the encoder's result with the intent to correct the
> encoder are near-sighted (i.e. suffer from the context-free approach). If
> {{source}} had a backslash followed by a dash, i.e. {{raw }}, the
> {{forJavaScript}} call would properly change the backslash into 2 backslashes
> {{raw }} (this would result in the javascript engine
> turning the string literal back to {{raw }}). But the subsequent
> {{replace}} call will destroy the context of the second backslash, turning
> the string into {{raw u002D}} which would turn to {{raw
> u002D}} in the javascript engine's variable.
> I argue for dropping the {{.replace()}} call (aiming at disabling malicious
> comment injection) here and encoding the opening angle bracket {{raw <}} as
> {{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
> protect against both the malicious comment injection and the injection of
> closing script tags {{raw script>}} forcing the javascript
> interpreter to drop out of the string literal context and drop out of the
> script context.
> The existing prefixing of forward slashes with a backslash agrees with JSON
> but not with Javascript. It should be removed in favour of replacing just the
> opening angle bracket.
> {noformat}
> SingleEscapeCharacter :: one of
> ' " \ b f n r t v
> {noformat}
> [https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
> [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> I noticed that JSONObject#toString suffers from the same idea of a
> non-universal protection of the forward slash. I guess both XSSAPI and
> JSONObject#toString reuse the same code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
[
https://issues.apache.org/jira/browse/SLING-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989033#comment-16989033
]
Ilguiz Latypov edited comment on SLING-8879 at 12/5/19 5:58 PM:
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML
or XHTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode with {{raw u}}
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} against the mandatory HTML entity decoding in
XHTML (but not HTML) documents. This decoding applies to text both outside and
inside the script tag.
was (Author: ilatypov):
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode with {{raw u}}
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} against the mandatory HTML entity decoding in
XHTML (but not HTML) documents. This decoding applies to text both outside and
inside the script tag.
> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct
> for pasting into a javascript string literal
>
>
> Key: SLING-8879
> URL: https://issues.apache.org/jira/browse/SLING-8879
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
> Reporter: Ilguiz Latypov
>Priority: Minor
>
> The current implementation risks exceptions in strict javascript engines.
> |return source == null ? null :
> Encode.forJavaScript(source).replace("-", "u002D");|
> Substitutes on top of the encoder's result with the intent to correct the
> encoder are near-sighted (i.e. suffer from the context-free approach). If
> {{source}} had a backslash followed by a dash, i.e. {{raw }}, the
> {{forJavaScript}} call would properly change the backslash into 2 backslashes
> {{raw }} (this would result in the javascript engine
> turning the string literal back to {{raw }}). But the subsequent
> {{replace}} call will destroy the context of the second backslash, turning
> the string into {{raw u002D}} which would turn to {{raw
> u002D}} in the javascript engine's variable.
> I argue for dropping the {{.replace()}} call (aiming at disabling malicious
> comment injection) here and encoding the opening angle bracket {{raw <}} as
> {{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
> protect against both the malicious comment injection and the injection of
> closing script tags {{raw script>}} forcing the javascript
> interpreter to drop out of the string literal context and drop out of the
> script context.
> The existing prefixing of forward slashes with a backslash agrees with JSON
> but not with Javascript. It should be removed in favour of replacing just the
> opening angle bracket.
> {noformat}
> SingleEscapeCharacter :: one of
> ' " \ b f n r t v
> {noformat}
> [https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
> [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> I noticed that JSONObject#toString suffers from the same idea of a
> non-universal protection of the forward slash. I guess both XSSAPI and
> JSONObject#toString reuse the same code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
[
https://issues.apache.org/jira/browse/SLING-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989033#comment-16989033
]
Ilguiz Latypov edited comment on SLING-8879 at 12/5/19 5:58 PM:
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode with {{raw u}}
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} against the mandatory HTML entity decoding in
XHTML (but not HTML) documents. This decoding applies to text both outside and
inside the script tag.
was (Author: ilatypov):
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode with {{raw u}}
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} without a specific concern.
> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct
> for pasting into a javascript string literal
>
>
> Key: SLING-8879
> URL: https://issues.apache.org/jira/browse/SLING-8879
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
> Reporter: Ilguiz Latypov
>Priority: Minor
>
> The current implementation risks exceptions in strict javascript engines.
> |return source == null ? null :
> Encode.forJavaScript(source).replace("-", "u002D");|
> Substitutes on top of the encoder's result with the intent to correct the
> encoder are near-sighted (i.e. suffer from the context-free approach). If
> {{source}} had a backslash followed by a dash, i.e. {{raw }}, the
> {{forJavaScript}} call would properly change the backslash into 2 backslashes
> {{raw }} (this would result in the javascript engine
> turning the string literal back to {{raw }}). But the subsequent
> {{replace}} call will destroy the context of the second backslash, turning
> the string into {{raw u002D}} which would turn to {{raw
> u002D}} in the javascript engine's variable.
> I argue for dropping the {{.replace()}} call (aiming at disabling malicious
> comment injection) here and encoding the opening angle bracket {{raw <}} as
> {{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
> protect against both the malicious comment injection and the injection of
> closing script tags {{raw script>}} forcing the javascript
> interpreter to drop out of the string literal context and drop out of the
> script context.
> The existing prefixing of forward slashes with a backslash agrees with JSON
> but not with Javascript. It should be removed in favour of replacing just the
> opening angle bracket.
> {noformat}
> SingleEscapeCharacter :: one of
> ' " \ b f n r t v
> {noformat}
> [https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
> [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> I noticed that JSONObject#toString suffers from the same idea of a
> non-universal protection of the forward slash. I guess both XSSAPI and
> JSONObject#toString reuse the same code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
[
https://issues.apache.org/jira/browse/SLING-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989033#comment-16989033
]
Ilguiz Latypov edited comment on SLING-8879 at 12/5/19 5:55 PM:
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode with {{raw u}}
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} without a specific concern.
was (Author: ilatypov):
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} without a specific concern.
> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct
> for pasting into a javascript string literal
>
>
> Key: SLING-8879
> URL: https://issues.apache.org/jira/browse/SLING-8879
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
> Reporter: Ilguiz Latypov
>Priority: Minor
>
> The current implementation risks exceptions in strict javascript engines.
> |return source == null ? null :
> Encode.forJavaScript(source).replace("-", "u002D");|
> Substitutes on top of the encoder's result with the intent to correct the
> encoder are near-sighted (i.e. suffer from the context-free approach). If
> {{source}} had a backslash followed by a dash, i.e. {{raw }}, the
> {{forJavaScript}} call would properly change the backslash into 2 backslashes
> {{raw }} (this would result in the javascript engine
> turning the string literal back to {{raw }}). But the subsequent
> {{replace}} call will destroy the context of the second backslash, turning
> the string into {{raw u002D}} which would turn to {{raw
> u002D}} in the javascript engine's variable.
> I argue for dropping the {{.replace()}} call (aiming at disabling malicious
> comment injection) here and encoding the opening angle bracket {{raw <}} as
> {{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
> protect against both the malicious comment injection and the injection of
> closing script tags {{raw script>}} forcing the javascript
> interpreter to drop out of the string literal context and drop out of the
> script context.
> The existing prefixing of forward slashes with a backslash agrees with JSON
> but not with Javascript. It should be removed in favour of replacing just the
> opening angle bracket.
> {noformat}
> SingleEscapeCharacter :: one of
> ' " \ b f n r t v
> {noformat}
> [https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
> [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> I noticed that JSONObject#toString suffers from the same idea of a
> non-universal protection of the forward slash. I guess both XSSAPI and
> JSONObject#toString reuse the same code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
[
https://issues.apache.org/jira/browse/SLING-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989033#comment-16989033
]
Ilguiz Latypov commented on SLING-8879:
---
I also see a suggestion to fool-proof more characters serialized as JSON
strings in case these strings are embedded into a javascript embedded in HTML.
https://security.stackexchange.com/questions/11091/is-this-json-encoding-vulnerable-to-cdata-injection/11097#11097
This suggests to encode
* the opening angle bracket {{raw }} against closing the script tag or
opening a comment tag,
* the closing angle bracket {{raw }} against closing a possible CDATA
wrapper around the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against
disrupting the javascript engine.
* the ampersand {{raw }} without a specific concern.
> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct
> for pasting into a javascript string literal
>
>
> Key: SLING-8879
> URL: https://issues.apache.org/jira/browse/SLING-8879
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
> Reporter: Ilguiz Latypov
>Priority: Minor
>
> The current implementation risks exceptions in strict javascript engines.
> |return source == null ? null :
> Encode.forJavaScript(source).replace("-", "u002D");|
> Substitutes on top of the encoder's result with the intent to correct the
> encoder are near-sighted (i.e. suffer from the context-free approach). If
> {{source}} had a backslash followed by a dash, i.e. {{raw }}, the
> {{forJavaScript}} call would properly change the backslash into 2 backslashes
> {{raw }} (this would result in the javascript engine
> turning the string literal back to {{raw }}). But the subsequent
> {{replace}} call will destroy the context of the second backslash, turning
> the string into {{raw u002D}} which would turn to {{raw
> u002D}} in the javascript engine's variable.
> I argue for dropping the {{.replace()}} call (aiming at disabling malicious
> comment injection) here and encoding the opening angle bracket {{raw <}} as
> {{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
> protect against both the malicious comment injection and the injection of
> closing script tags {{raw script>}} forcing the javascript
> interpreter to drop out of the string literal context and drop out of the
> script context.
> The existing prefixing of forward slashes with a backslash agrees with JSON
> but not with Javascript. It should be removed in favour of replacing just the
> opening angle bracket.
> {noformat}
> SingleEscapeCharacter :: one of
> ' " \ b f n r t v
> {noformat}
> [https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
> [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> I noticed that JSONObject#toString suffers from the same idea of a
> non-universal protection of the forward slash. I guess both XSSAPI and
> JSONObject#toString reuse the same code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
[
https://issues.apache.org/jira/browse/SLING-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989011#comment-16989011
]
Ilguiz Latypov edited comment on SLING-8879 at 12/5/19 5:40 PM:
I see SLING-6679 replaced JSONObject with Johnzon in year 2017 which has a
simple serializer that does not reuse the "for javascript" encoder. On the
other hand, Johnzon would not protect against the closing script tag injection
or the open comment tag injection in cases where the javascript string literal
is embedded with the HTML response.
I see Johnzon substitutes the double quotes, as required by JSON and by the
need to protect against the attack where malicious payload drops out of the
javascript string literal context in a Javascript embedded in HTML. Of course.
It would be nice if Johnzon replaced the open angle bracket {{raw }} with
an ASCII presentation of the respective Unicode, {{raw u003C}}, which is
also compatible with both JSON and Javascript.
https://github.com/apache/johnzon/blob/master/johnzon-core/src/main/java/org/apache/johnzon/core/Strings.java#L64
XSSAPI encodeForJSString() could reuse Johnzon's above serialization. (I guess
this would require accessing Johnzon via Sling's service provider interface to
an abstract JSON implementation).
Our older AEM code still uses the older JSONObject, but I guess there would not
be a security (built-in XSS protection against abuse of javascript code with
string literals embedded in HTML) or stability (strict javascript engine
failing to parse the backslash-forwardslash encoding I observed in
JSONObject#toString) update to that version of Sling.
was (Author: ilatypov):
I see SLING-6679 replaced JSONObject with Johnzon in year 2017 which has a
simple serializer that does not reuse the "for javascript" encoder. On the
other hand, Johnzon would not protect against the closing script tag injection
or the open comment tag injection in cases where the javascript string literal
is embedded with the HTML response.
I see Johnzon substitutes the double quotes, as required by JSON and by the
need to protect against the attack by dropping out of the javascript string
literal context in a Javascript embedded in HTML. Of course.
It would be nice if Johnzon replaced the open angle bracket {{raw }} with
an ASCII presentation of the respective Unicode, {{raw u003C}}, which is
also compatible with both JSON and Javascript.
https://github.com/apache/johnzon/blob/master/johnzon-core/src/main/java/org/apache/johnzon/core/Strings.java#L64
XSSAPI encodeForJSString() could reuse Johnzon's above serialization. (I guess
this would require accessing Johnzon via Sling's service provider interface to
an abstract JSON implementation).
Our older AEM code still uses the older JSONObject, but I guess there would not
be a security (built-in XSS protection against abuse of javascript code with
string literals embedded in HTML) or stability (string javascript engine
failing to parse the backslash-forwardslash encoding I observed in
JSONObject#toString) update to that version of Sling.
> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct
> for pasting into a javascript string literal
>
>
> Key: SLING-8879
> URL: https://issues.apache.org/jira/browse/SLING-8879
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
>Reporter: Ilguiz Latypov
>Priority: Minor
>
> The current implementation risks exceptions in strict javascript engines.
> |return source == null ? null :
> Encode.forJavaScript(source).replace("-", "u002D");|
> Substitutes on top of the encoder's result with the intent to correct the
> encoder are near-sighted (i.e. suffer from the context-free approach). If
> {{source}} had a backslash followed by a dash, i.e. {{raw }}, the
> {{forJavaScript}} call would properly change the backslash into 2 backslashes
> {{raw }} (this would result in the javascript engine
> turning the string literal back to {{raw }}). But the subsequent
> {{replace}} call will destroy the context of the second backslash, turning
> the string into {{raw u002D}} which would turn to {{raw
> u002D}} in the javascript engine's variable.
> I argue for dropping the {{.replace()}} call (aiming at disabling malicious
> comment injection) here and encoding the opening angle bracket {{raw <}} as
> {{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
> protect against both the malicious comment injection and the injection of
> closing script tags {{raw script>}} forcing th
[jira] [Commented] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
[
https://issues.apache.org/jira/browse/SLING-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989011#comment-16989011
]
Ilguiz Latypov commented on SLING-8879:
---
I see SLING-6679 replaced JSONObject with Johnzon in year 2017 which has a
simple serializer that does not reuse the "for javascript" encoder. On the
other hand, Johnzon would not protect against the closing script tag injection
or the open comment tag injection in cases where the javascript string literal
is embedded with the HTML response.
I see Johnzon substitutes the double quotes, as required by JSON and by the
need to protect against the attack by dropping out of the javascript string
literal context in a Javascript embedded in HTML. Of course.
It would be nice if Johnzon replaced the open angle bracket {{raw }} with
an ASCII presentation of the respective Unicode, {{raw u003C}}, which is
also compatible with both JSON and Javascript.
https://github.com/apache/johnzon/blob/master/johnzon-core/src/main/java/org/apache/johnzon/core/Strings.java#L64
XSSAPI encodeForJSString() could reuse Johnzon's above serialization. (I guess
this would require accessing Johnzon via Sling's service provider interface to
an abstract JSON implementation).
Our older AEM code still uses the older JSONObject, but I guess there would not
be a security (built-in XSS protection against abuse of javascript code with
string literals embedded in HTML) or stability (string javascript engine
failing to parse the backslash-forwardslash encoding I observed in
JSONObject#toString) update to that version of Sling.
> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct
> for pasting into a javascript string literal
>
>
> Key: SLING-8879
> URL: https://issues.apache.org/jira/browse/SLING-8879
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
>Reporter: Ilguiz Latypov
>Priority: Minor
>
> The current implementation risks exceptions in strict javascript engines.
> |return source == null ? null :
> Encode.forJavaScript(source).replace("-", "u002D");|
> Substitutes on top of the encoder's result with the intent to correct the
> encoder are near-sighted (i.e. suffer from the context-free approach). If
> {{source}} had a backslash followed by a dash, i.e. {{raw }}, the
> {{forJavaScript}} call would properly change the backslash into 2 backslashes
> {{raw }} (this would result in the javascript engine
> turning the string literal back to {{raw }}). But the subsequent
> {{replace}} call will destroy the context of the second backslash, turning
> the string into {{raw u002D}} which would turn to {{raw
> u002D}} in the javascript engine's variable.
> I argue for dropping the {{.replace()}} call (aiming at disabling malicious
> comment injection) here and encoding the opening angle bracket {{raw <}} as
> {{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
> protect against both the malicious comment injection and the injection of
> closing script tags {{raw script>}} forcing the javascript
> interpreter to drop out of the string literal context and drop out of the
> script context.
> The existing prefixing of forward slashes with a backslash agrees with JSON
> but not with Javascript. It should be removed in favour of replacing just the
> opening angle bracket.
> {noformat}
> SingleEscapeCharacter :: one of
> ' " \ b f n r t v
> {noformat}
> [https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
> [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> I noticed that JSONObject#toString suffers from the same idea of a
> non-universal protection of the forward slash. I guess both XSSAPI and
> JSONObject#toString reuse the same code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
[
https://issues.apache.org/jira/browse/SLING-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988929#comment-16988929
]
Ilguiz Latypov commented on SLING-8879:
---
https://github.com/apache/sling-org-apache-sling-xss/blob/a827eb7/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java#L412
> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct
> for pasting into a javascript string literal
>
>
> Key: SLING-8879
> URL: https://issues.apache.org/jira/browse/SLING-8879
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
> Reporter: Ilguiz Latypov
>Priority: Minor
>
> The current implementation risks exceptions in strict javascript engines.
> |return source == null ? null :
> Encode.forJavaScript(source).replace("-", "u002D");|
> Substitutes on top of the encoder's result with the intent to correct the
> encoder are near-sighted (i.e. suffer from the context-free approach). If
> {{source}} had a backslash followed by a dash, i.e. {{raw }}, the
> {{forJavaScript}} call would properly change the backslash into 2 backslashes
> {{raw }} (this would result in the javascript engine
> turning the string literal back to {{raw }}). But the subsequent
> {{replace}} call will destroy the context of the second backslash, turning
> the string into {{raw u002D}} which would turn to {{raw
> u002D}} in the javascript engine's variable.
> I argue for dropping the {{.replace()}} call (aiming at disabling malicious
> comment injection) here and encoding the opening angle bracket {{raw <}} as
> {{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
> protect against both the malicious comment injection and the injection of
> closing script tags {{raw script>}} forcing the javascript
> interpreter to drop out of the string literal context and drop out of the
> script context.
> The existing prefixing of forward slashes with a backslash agrees with JSON
> but not with Javascript. It should be removed in favour of replacing just the
> opening angle bracket.
> {noformat}
> SingleEscapeCharacter :: one of
> ' " \ b f n r t v
> {noformat}
> [https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
> [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> I noticed that JSONObject#toString suffers from the same idea of a
> non-universal protection of the forward slash. I guess both XSSAPI and
> JSONObject#toString reuse the same code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
Ilguiz Latypov created SLING-8879:
-
Summary: Make JSONObject#toString and XSSAPI#encodeForJSString
both safe and correct for pasting into a javascript string literal
Key: SLING-8879
URL: https://issues.apache.org/jira/browse/SLING-8879
Project: Sling
Issue Type: Bug
Components: XSS Protection API
Reporter: Ilguiz Latypov
The current implementation risks exceptions in strict javascript engines.
|return source == null ? null :
Encode.forJavaScript(source).replace("-", "u002D");|
Substitutes on top of the encoder's result with the intent to correct the
encoder are near-sighted (i.e. suffer from the context-free approach). If
{{source}} had a backslash followed by a dash, i.e. {{raw }}, the
{{forJavaScript}} call would properly change the backslash into 2 backslashes
{{raw }} (this would result in the javascript engine turning
the string literal back to {{raw }}). But the subsequent
{{replace}} call will destroy the context of the second backslash, turning the
string into {{raw u002D}} which would turn to {{raw u002D}}
in the javascript engine's variable.
I argue for dropping the {{.replace()}} call (aiming at disabling malicious
comment injection) here and encoding the opening angle bracket {{raw <}} as
{{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
protect against both the malicious comment injection and the injection of
closing script tags {{raw script>}} forcing the javascript
interpreter to drop out of the string literal context and drop out of the
script context.
The existing prefixing of forward slashes with a backslash agrees with JSON but
not with Javascript. It should be removed in favour of replacing just the
opening angle bracket.
{noformat}
SingleEscapeCharacter :: one of
' " \ b f n r t v
{noformat}
[https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
I noticed that JSONObject#toString suffers from the same idea of a
non-universal protection of the forward slash. I guess both XSSAPI and
JSONObject#toString reuse the same code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
[
https://issues.apache.org/jira/browse/SLING-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988471#comment-16988471
]
Ilguiz Latypov commented on SLING-5946:
---
[~radu], [~rombert], [~vladb]
> XSSAPI#encodeForJSString is not restrictive enough
> --
>
> Key: SLING-5946
> URL: https://issues.apache.org/jira/browse/SLING-5946
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Vlad Bailescu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: XSS Protection API 1.0.12
>
> Attachments: SLING_5946.patch
>
>
> Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding
> {{}} and {{
[jira] [Comment Edited] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
[
https://issues.apache.org/jira/browse/SLING-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988288#comment-16988288
]
Ilguiz Latypov edited comment on SLING-5946 at 12/4/19 11:32 PM:
-
Please reopen this due to an improper implementation risking exceptions in
strict javascript engines.
|return source == null ? null :
Encode.forJavaScript(source).replace("-", "u002D");|
Substitutes on top of the encoder's result with the intent to correct the
encoder are near-sighted (i.e. suffer from the context-free approach). If
{{source}} had a backslash followed by a dash, i.e. {{raw }}, the
{{forJavaScript}} call would properly change the backslash into 2 backslashes
{{raw }} (this would result in the javascript engine turning
the string literal back to {{raw }}). But the subsequent
{{replace}} call will destroy the context of the second backslash, turning the
string into {{raw u002D}} which would turn to {{raw u002D}}
in the javascript engine's variable.
I argue for dropping the {{.replace()}} call (aiming at disabling malicious
comment injection) here and encoding the opening angle bracket {{raw <}} as
{{raw u003C}} in the {{Encode.forJavaScript}} implementation. This will
protect against both the malicious comment injection and the injection of
closing script tags {{raw script>}} forcing the javascript
interpreter to drop out of the string literal context and drop out of the
script context.
The existing prefixing of forward slashes with a backslash agrees with JSON but
not with Javascript. It should be removed in favour of replacing just the
opening angle bracket.
{noformat}
SingleEscapeCharacter :: one of
' " \ b f n r t v
{noformat}
[https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
was (Author: ilatypov):
Please reopen this due to an improper implementation risking exceptions in
strict javascript engines.
|return source == null ? null :
Encode.forJavaScript(source).replace("-", "u002D");|
Substitutes on top of the encoder's result with the intent to correct the
encoder are near-sighted (i.e. suffer from the context-free approach). If
{{source}} had a backslash followed by a dash, i.e. {{raw -}}, the
{{forJavaScript}} call would properly change the backslash into 2 backslashes
{{raw -}} (this would result in the javascript engine turning the
string literal back to {{raw -}}). But the subsequent {{replace}} call
will destroy the context of the second backslash, turning the string into {{raw
u002D}} which would turn to {{raw u002D}} in the javascript
engine's variable.
I argue for dropping the {{.replace()}} call here and encoding the opening
angle bracket {{raw <}} as {{raw u003C}} in the {{Encode.forJavaScript}}
implementation. This will also protect against the closing script tags {{raw
script>}} forcing the javascript interpreter to drop out of the
string literal context and drop out of the script context.
The existing prefixing of forward slashes with a backslash agrees with JSON but
not with Javascript. It should be removed in favour of replacing just the
opening angle bracket.
{noformat}
SingleEscapeCharacter :: one of
' " \ b f n r t v
{noformat}
[https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> XSSAPI#encodeForJSString is not restrictive enough
> --
>
> Key: SLING-5946
> URL: https://issues.apache.org/jira/browse/SLING-5946
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Vlad Bailescu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: XSS Protection API 1.0.12
>
> Attachments: SLING_5946.patch
>
>
> Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding
> {{}} and {{
[jira] [Comment Edited] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
[
https://issues.apache.org/jira/browse/SLING-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988288#comment-16988288
]
Ilguiz Latypov edited comment on SLING-5946 at 12/4/19 11:30 PM:
-
Please reopen this due to an improper implementation risking exceptions in
strict javascript engines.
|return source == null ? null :
Encode.forJavaScript(source).replace("-", "u002D");|
Substitutes on top of the encoder's result with the intent to correct the
encoder are near-sighted (i.e. suffer from the context-free approach). If
{{source}} had a backslash followed by a dash, i.e. {{raw -}}, the
{{forJavaScript}} call would properly change the backslash into 2 backslashes
{{raw -}} (this would result in the javascript engine turning the
string literal back to {{raw -}}). But the subsequent {{replace}} call
will destroy the context of the second backslash, turning the string into {{raw
u002D}} which would turn to {{raw u002D}} in the javascript
engine's variable.
I argue for dropping the {{.replace()}} call here and encoding the opening
angle bracket {{raw <}} as {{raw u003C}} in the {{Encode.forJavaScript}}
implementation. This will also protect against the closing script tags {{raw
script>}} forcing the javascript interpreter to drop out of the
string literal context and drop out of the script context.
The existing prefixing of forward slashes with a backslash agrees with JSON but
not with Javascript. It should be removed in favour of replacing just the
opening angle bracket.
{noformat}
SingleEscapeCharacter :: one of
' " \ b f n r t v
{noformat}
[https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
was (Author: ilatypov):
Please reopen this due to an improper implementation risking exceptions in
strict javascript engines.
|return source == null ? null : Encode.forJavaScript(source).replace("\\-",
"\\u002D");|
Substitutes on top of the encoder's result with the intent to correct the
encoder are near-sighted (i.e. suffer from the context-free approach). If
{{source}} had a backslash followed by a dash, i.e. {{raw \--}}, the
{{forJavaScript}} call would properly change the backslash into 2 backslashes
{{raw \\}} (this would result in the javascript engine turning the string
literal back to {{raw \-}}). But the subsequent {{replace}} call will destroy
the context of the second backslash, turning the string into {{raw \\u002D}}
which would turn to {{raw \u002D}} in the javascript engine's variable.
I argue for dropping the {{.replace()}} call here and encoding the opening
angle bracket {{raw <}} as {{raw \u003C}} in the {{Encode.forJavaScript}}
implementation. This will also protect against the closing script tags {{raw
}} forcing the javascript interpreter to drop out of the string
literal context and drop out of the script context.
The existing prefixing of forward slashes with a backslash agrees with JSON but
not with Javascript. It should be removed in favour of replacing just the
opening angle bracket.
{noformat}
SingleEscapeCharacter :: one of
' " \ b f n r t v
{noformat}
[https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> XSSAPI#encodeForJSString is not restrictive enough
> --
>
> Key: SLING-5946
> URL: https://issues.apache.org/jira/browse/SLING-5946
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Vlad Bailescu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: XSS Protection API 1.0.12
>
> Attachments: SLING_5946.patch
>
>
> Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding
> {{}} and {{
[jira] [Comment Edited] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
[
https://issues.apache.org/jira/browse/SLING-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988288#comment-16988288
]
Ilguiz Latypov edited comment on SLING-5946 at 12/4/19 11:27 PM:
-
Please reopen this due to an improper implementation risking exceptions in
strict javascript engines.
|return source == null ? null : Encode.forJavaScript(source).replace("\\-",
"\\u002D");|
Substitutes on top of the encoder's result with the intent to correct the
encoder are near-sighted (i.e. suffer from the context-free approach). If
{{source}} had a backslash followed by a dash, i.e. {{raw \--}}, the
{{forJavaScript}} call would properly change the backslash into 2 backslashes
{{raw \\}} (this would result in the javascript engine turning the string
literal back to {{raw \-}}). But the subsequent {{replace}} call will destroy
the context of the second backslash, turning the string into {{raw \\u002D}}
which would turn to {{raw \u002D}} in the javascript engine's variable.
I argue for dropping the {{.replace()}} call here and encoding the opening
angle bracket {{raw <}} as {{raw \u003C}} in the {{Encode.forJavaScript}}
implementation. This will also protect against the closing script tags {{raw
}} forcing the javascript interpreter to drop out of the string
literal context and drop out of the script context.
The existing prefixing of forward slashes with a backslash agrees with JSON but
not with Javascript. It should be removed in favour of replacing just the
opening angle bracket.
{noformat}
SingleEscapeCharacter :: one of
' " \ b f n r t v
{noformat}
[https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
was (Author: ilatypov):
Please reopen this due to an improper implementation risking exceptions in
strict javascript engines.
|return source == null ? null :
Encode.forJavaScript(source).replace("-", "u002D");|
Substitutes on top of the encoder's result with the intent to correct the
encoder are near-sighted (i.e. suffer from the context-free approach). If
{{source}} had a backslash followed by a dash {{raw -}}, the
{{forJavaScript}} call would properly change the backslash into 2 backslashes
{{raw -}} (this would result in the javascript engine turning the
string literal back to {{raw -}}). But the subsequent {{replace}} call
will destroy the context of the second backslash, turning the string into {{raw
u002D}} which would turn to {{raw u002D}} in the javascript
engine's variable.
I argue for dropping the {{.replace()}} call here and encoding the opening
angle bracket {{raw <}} as {{raw u003C}} in the {{Encode.forJavaScript}}
implementation. This will also protect against the closing script tags {{raw
/script>}} forcing the javascript interpreter to drop out of the string
literal context and drop out of the script context.
The existing prefixing of forward slashes with a backslash agrees with JSON but
not with Javascript. It should be removed in favour of replacing just the
opening angle bracket.
{noformat}
SingleEscapeCharacter :: one of
' " \ b f n r t v
{noformat}
https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation
> XSSAPI#encodeForJSString is not restrictive enough
> --
>
> Key: SLING-5946
> URL: https://issues.apache.org/jira/browse/SLING-5946
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Vlad Bailescu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: XSS Protection API 1.0.12
>
> Attachments: SLING_5946.patch
>
>
> Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding
> {{}} and {{
[jira] [Comment Edited] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
[
https://issues.apache.org/jira/browse/SLING-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988288#comment-16988288
]
Ilguiz Latypov edited comment on SLING-5946 at 12/4/19 11:26 PM:
-
Please reopen this due to an improper implementation risking exceptions in
strict javascript engines.
|return source == null ? null :
Encode.forJavaScript(source).replace("-", "u002D");|
Substitutes on top of the encoder's result with the intent to correct the
encoder are near-sighted (i.e. suffer from the context-free approach). If
{{source}} had a backslash followed by a dash {{raw -}}, the
{{forJavaScript}} call would properly change the backslash into 2 backslashes
{{raw -}} (this would result in the javascript engine turning the
string literal back to {{raw -}}). But the subsequent {{replace}} call
will destroy the context of the second backslash, turning the string into {{raw
u002D}} which would turn to {{raw u002D}} in the javascript
engine's variable.
I argue for dropping the {{.replace()}} call here and encoding the opening
angle bracket {{raw <}} as {{raw u003C}} in the {{Encode.forJavaScript}}
implementation. This will also protect against the closing script tags {{raw
/script>}} forcing the javascript interpreter to drop out of the string
literal context and drop out of the script context.
The existing prefixing of forward slashes with a backslash agrees with JSON but
not with Javascript. It should be removed in favour of replacing just the
opening angle bracket.
{noformat}
SingleEscapeCharacter :: one of
' " \ b f n r t v
{noformat}
https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation
was (Author: ilatypov):
Please reopen this due to an improper implementation risking exceptions in
strict javascript engines.
| return source == null ? null : Encode.forJavaScript(source).replace("\\-",
"\\u002D");|
Substitutes on top of the encoder's result with the intent to correct the
encoder are near-sighted (i.e. suffer from the context-free approach). If
{{source}} had a backslash followed by a dash {{raw \-}}, the {{forJavaScript}}
call would properly change the backslash into 2 backslashes {{raw \\-}} (this
would result in the javascript engine turning the string literal back to {{raw
\-}}). But the subsequent {{replace}} call will destroy the context of the
second backslash, turning the string into {{raw \\u002D}} which would turn to
{{raw \u002D}} in the javascript engine's variable.
I argue for dropping the {{.replace()}} call here and encoding the opening
angle bracket {{raw <}} as {{raw \u003C}} in the Encode.forJavaScript()
implementation. This will also protect against the closing script tags {{raw
}} forcing the javascript interpreter to drop out of the string
literal context and drop out of the script context. The existing prefixing of
forward slashes with a backslash agrees with JSON but not with Javascript. It
should be removed in favour of replacing just the opening angle bracket.
> XSSAPI#encodeForJSString is not restrictive enough
> --
>
> Key: SLING-5946
> URL: https://issues.apache.org/jira/browse/SLING-5946
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Vlad Bailescu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: XSS Protection API 1.0.12
>
> Attachments: SLING_5946.patch
>
>
> Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding
> {{}} and {{
[jira] [Commented] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
[
https://issues.apache.org/jira/browse/SLING-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988288#comment-16988288
]
Ilguiz Latypov commented on SLING-5946:
---
Please reopen this due to an improper implementation risking exceptions in
strict javascript engines.
| return source == null ? null : Encode.forJavaScript(source).replace("\\-",
"\\u002D");|
Substitutes on top of the encoder's result with the intent to correct the
encoder are near-sighted (i.e. suffer from the context-free approach). If
{{source}} had a backslash followed by a dash {{raw \-}}, the {{forJavaScript}}
call would properly change the backslash into 2 backslashes {{raw \\-}} (this
would result in the javascript engine turning the string literal back to {{raw
\-}}). But the subsequent {{replace}} call will destroy the context of the
second backslash, turning the string into {{raw \\u002D}} which would turn to
{{raw \u002D}} in the javascript engine's variable.
I argue for dropping the {{.replace()}} call here and encoding the opening
angle bracket {{raw <}} as {{raw \u003C}} in the Encode.forJavaScript()
implementation. This will also protect against the closing script tags {{raw
}} forcing the javascript interpreter to drop out of the string
literal context and drop out of the script context. The existing prefixing of
forward slashes with a backslash agrees with JSON but not with Javascript. It
should be removed in favour of replacing just the opening angle bracket.
> XSSAPI#encodeForJSString is not restrictive enough
> --
>
> Key: SLING-5946
> URL: https://issues.apache.org/jira/browse/SLING-5946
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Vlad Bailescu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: XSS Protection API 1.0.12
>
> Attachments: SLING_5946.patch
>
>
> Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding
> {{}} and {{
Bug#931041: Acknowledgement (basez: fails to decode base64url strings with the padding trimmed)
Sorry it failed even with the padding, so I don't know what is failing in basez.
Bug#931041: basez: fails to decode base64url strings with the padding trimmed
Package: basez Version: 1.6-3 Severity: important Tags: upstream Dear Maintainer, * Decoding a JWT signature showed that omitting the padding (as required by one of the JWS RFC) causes a failure in base64url -d. $ echo -n Igzmk82YO1cNEjjEF0WQMEv4tGPLrgm43Yrh_bFvHStV2Qju-eebyN82F-fASOZqQxOGL9sU_g6ewloKNk5yO7Dt__YqJ9GROXiovYD6cM4G2UboYn7BCf4lH84kfRNZAxrVNOOC50aYuVTvTGQrxXUooq9KnCkQzeZLbl26Vw7Yq0fP_D39ztoNu5Oyy0Nar_iHRyyPqAyia3VhrcETIK199IUG4QK0Rj2UIfEg6qPhVrE2rVKZy2zd4s871sLg0XuqOdwwZsYsIBP0tcd2C2-6HTfDNlBEoWo_XtF3DbkvNiBA75xHcxlXkq__ytCdicXDkdfOiS39IfsyzzmGEg== | tr -- '-_' '+/' | base64 -d | xxd -g0 -ps -c20 220ce693cd983b570d1238c4174590304bf8b463 cbae09b8dd8ae1fdb16f1d2b55d908eef9e79bc8 df3617e7c048e66a4313862fdb14fe0e9ec25a0a 364e723bb0edfff62a27d1913978a8bd80fa70ce 06d946e8627ec109fe251fce247d1359031ad534 e382e74698b954ef4c642bc57528a2af4a9c2910 cde64b6e5dba570ed8ab47cffc3dfdceda0dbb93 b2cb435aaff887472c8fa80ca26b7561adc11320 ad7df48506e102b4463d9421f120eaa3e156b136 ad5299cb6cdde2cf3bd6c2e0d17baa39dc3066c6 2c2013f4b5c7760b6fba1d37c3365044a16a3f5e d1770db92f362040ef9c4773195792afffcad09d 89c5c391d7ce892dfd21fb32cf398612 $ echo -n Igzmk82YO1cNEjjEF0WQMEv4tGPLrgm43Yrh_bFvHStV2Qju-eebyN82F-fASOZqQxOGL9sU_g6ewloKNk5yO7Dt__YqJ9GROXiovYD6cM4G2UboYn7BCf4lH84kfRNZAxrVNOOC50aYuVTvTGQrxXUooq9KnCkQzeZLbl26Vw7Yq0fP_D39ztoNu5Oyy0Nar_iHRyyPqAyia3VhrcETIK199IUG4QK0Rj2UIfEg6qPhVrE2rVKZy2zd4s871sLg0XuqOdwwZsYsIBP0tcd2C2-6HTfDNlBEoWo_XtF3DbkvNiBA75xHcxlXkq__ytCdicXDkdfOiS39IfsyzzmGEg== | base64url -d base64url: invalid input -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.16-x86_64-linode118 (SMP w/1 CPU core; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages basez depends on: ii libc6 2.28-10 basez recommends no packages. basez suggests no packages. -- no debconf information
Bug#712099: appears a feature not a bug
I contacted the author and he pointed to the "-a" option that controls the search behaviour. I found the "-A" option to follow my expectation of a forward and backward search, -a or --search-skip-screen By default, forward searches start at the top of the displayed screen and backwards searches start at the bottom of the displayed screen (except for repeated searches invoked by the n or N commands, which start after or before the "target" line respectively; see the -j op‐ tion for more about the target line). The -a option causes forward searches to instead start at the bottom of the screen and backward searches to start at the top of the screen, thus skipping all lines displayed on the screen. -A or --SEARCH-SKIP-SCREEN Causes all forward searches (not just non-repeated searches) to start just after the target line, and all backward searches to start just before the target line. Thus, forward searches will skip part of the displayed screen (from the first line up to and including the target line). Similarly backwards searches will skip the displayed screen from the last line up to and including the target line. This was the default behavior in less versions prior to 441. I don't understand why the default behaviour needed to change. --
[jira] [Created] (GROOVY-9019) triple-single and triple-double quotes handle backslash escapes equally
Ilguiz Latypov created GROOVY-9019:
--
Summary: triple-single and triple-double quotes handle backslash
escapes equally
Key: GROOVY-9019
URL: https://issues.apache.org/jira/browse/GROOVY-9019
Project: Groovy
Issue Type: Documentation
Components: Documentation
Reporter: Ilguiz Latypov
The documentation implies that triple-single quotes treat only escaping of
single quotes with backslashes.
{code:java}
|'\''
316 |single quote (for single quoted and triple single quoted strings)
317
318 |'\"'
319 |double quote (for double quoted and triple double quoted strings)
{code}
[https://gitbox.apache.org/repos/asf?p=groovy.git;a=blob;f=src/spec/doc/core-syntax.adoc;h=30b48fdfb4caafacae343f5dac9dde3372da65b2;hb=HEAD#l315]
My quick tests show that regardless of the surrounding triple quotes, backslash
escaping works equally on single and double quotes.
{code:java}
s = '''foo\"bar'''
println "The triple-single-quoted string with a backslash-double-quote inside:
${s}"
s = """foo\'bar"""
println "The triple-double-quoted string with a backslash-single-quote inside:
${s}"
{code}
{code:java}
The triple-single-quoted string with a backslash-double-quote inside: foo"bar
The triple-double-quoted string with a backslash-single-quote inside: foo'bar
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-9019) triple-single and triple-double quotes handle backslash escapes equally
[
https://issues.apache.org/jira/browse/GROOVY-9019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilguiz Latypov updated GROOVY-9019:
---
Description:
The documentation implies that triple-single quotes treat only escaping of
single quotes with backslashes.
{code:java}
315 |'\''
316 |single quote (for single quoted and triple single quoted strings)
317
318 |'\"'
319 |double quote (for double quoted and triple double quoted strings)
{code}
[https://gitbox.apache.org/repos/asf?p=groovy.git;a=blob;f=src/spec/doc/core-syntax.adoc;h=30b48fdfb4caafacae343f5dac9dde3372da65b2;hb=HEAD#l315]
My quick tests show that regardless of the surrounding triple quotes, backslash
escaping works equally on single and double quotes.
{code:java}
s = '''foo\"bar'''
println "The triple-single-quoted string with a backslash-double-quote inside:
${s}"
s = """foo\'bar"""
println "The triple-double-quoted string with a backslash-single-quote inside:
${s}"
{code}
{code:java}
The triple-single-quoted string with a backslash-double-quote inside: foo"bar
The triple-double-quoted string with a backslash-single-quote inside: foo'bar
{code}
was:
The documentation implies that triple-single quotes treat only escaping of
single quotes with backslashes.
{code:java}
|'\''
316 |single quote (for single quoted and triple single quoted strings)
317
318 |'\"'
319 |double quote (for double quoted and triple double quoted strings)
{code}
[https://gitbox.apache.org/repos/asf?p=groovy.git;a=blob;f=src/spec/doc/core-syntax.adoc;h=30b48fdfb4caafacae343f5dac9dde3372da65b2;hb=HEAD#l315]
My quick tests show that regardless of the surrounding triple quotes, backslash
escaping works equally on single and double quotes.
{code:java}
s = '''foo\"bar'''
println "The triple-single-quoted string with a backslash-double-quote inside:
${s}"
s = """foo\'bar"""
println "The triple-double-quoted string with a backslash-single-quote inside:
${s}"
{code}
{code:java}
The triple-single-quoted string with a backslash-double-quote inside: foo"bar
The triple-double-quoted string with a backslash-single-quote inside: foo'bar
{code}
> triple-single and triple-double quotes handle backslash escapes equally
> ---
>
> Key: GROOVY-9019
> URL: https://issues.apache.org/jira/browse/GROOVY-9019
> Project: Groovy
> Issue Type: Documentation
> Components: Documentation
>Reporter: Ilguiz Latypov
>Priority: Minor
>
> The documentation implies that triple-single quotes treat only escaping of
> single quotes with backslashes.
> {code:java}
> 315 |'\''
> 316 |single quote (for single quoted and triple single quoted strings)
> 317
> 318 |'\"'
> 319 |double quote (for double quoted and triple double quoted strings)
> {code}
> [https://gitbox.apache.org/repos/asf?p=groovy.git;a=blob;f=src/spec/doc/core-syntax.adoc;h=30b48fdfb4caafacae343f5dac9dde3372da65b2;hb=HEAD#l315]
>
> My quick tests show that regardless of the surrounding triple quotes,
> backslash escaping works equally on single and double quotes.
>
> {code:java}
> s = '''foo\"bar'''
> println "The triple-single-quoted string with a backslash-double-quote
> inside: ${s}"
> s = """foo\'bar"""
> println "The triple-double-quoted string with a backslash-single-quote
> inside: ${s}"
> {code}
>
> {code:java}
> The triple-single-quoted string with a backslash-double-quote inside: foo"bar
> The triple-double-quoted string with a backslash-single-quote inside: foo'bar
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-4777) GString cannot be cast to java.lang.String while iterating a collection from java
[
https://issues.apache.org/jira/browse/GROOVY-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilguiz Latypov updated GROOVY-4777:
---
Attachment: GStringTest.java
> GString cannot be cast to java.lang.String while iterating a collection from
> java
> -
>
> Key: GROOVY-4777
> URL: https://issues.apache.org/jira/browse/GROOVY-4777
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.7.10
> Environment: Linux
>Reporter: David Gomez
>Priority: Major
> Attachments: GStringTest.java, GStringTest.java, build.gradle
>
>
> When i try to iterate a map that contains GStrings i get a
> {noformat}
> java.lang.ClassCastException: org.codehaus.groovy.runtime.GStringImpl cannot
> be cast to java.lang.String
> at experiments.inputdata.GStringCastTest.testCast(GStringCastTest.java:24)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {noformat}
> Here is the code snippet:
> {code}
> ConfigSlurper slurper = new ConfigSlurper();
> String script =
> "example {\n" +
> " one = \"one\"\n" +
> " two = \"${one} + ${one}\"\n" +
> " three = \"${two} + ${one}\"\n" +
> "}";
> ConfigObject config = slurper.parse(script);
> Map e = (Map) config.get("example");
> for (String k : e.keySet()) {
> String v = e.get(k);
> System.out.println(v);
> }
> {code}
> See attached JUnit test case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-4777) GString cannot be cast to java.lang.String while iterating a collection from java
[
https://issues.apache.org/jira/browse/GROOVY-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilguiz Latypov updated GROOVY-4777:
---
Attachment: build.gradle
> GString cannot be cast to java.lang.String while iterating a collection from
> java
> -
>
> Key: GROOVY-4777
> URL: https://issues.apache.org/jira/browse/GROOVY-4777
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.7.10
> Environment: Linux
>Reporter: David Gomez
>Priority: Major
> Attachments: GStringTest.java, GStringTest.java, build.gradle
>
>
> When i try to iterate a map that contains GStrings i get a
> {noformat}
> java.lang.ClassCastException: org.codehaus.groovy.runtime.GStringImpl cannot
> be cast to java.lang.String
> at experiments.inputdata.GStringCastTest.testCast(GStringCastTest.java:24)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {noformat}
> Here is the code snippet:
> {code}
> ConfigSlurper slurper = new ConfigSlurper();
> String script =
> "example {\n" +
> " one = \"one\"\n" +
> " two = \"${one} + ${one}\"\n" +
> " three = \"${two} + ${one}\"\n" +
> "}";
> ConfigObject config = slurper.parse(script);
> Map e = (Map) config.get("example");
> for (String k : e.keySet()) {
> String v = e.get(k);
> System.out.println(v);
> }
> {code}
> See attached JUnit test case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-4777) GString cannot be cast to java.lang.String while iterating a collection from java
[
https://issues.apache.org/jira/browse/GROOVY-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577040#comment-16577040
]
Ilguiz Latypov commented on GROOVY-4777:
I doubt Groovy 1.7.6 could have an intentional or unintentional fix.
{noformat}
$ JAVA_HOME=c:/jdk8 ./gradlew
> Task :compileJava NO-SOURCE
> Task :processResources NO-SOURCE
> Task :classes UP-TO-DATE
> Task :compileTestJava
Note: C:\cygwin64\home\latypil\groovytest\GStringTest.java uses unchecked or
unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
> Task :processTestResources NO-SOURCE
> Task :testClasses
> Task :runSimple FAILED
Classpath: C:\cygwin64\home\latypil\groovytest\build\classes\java\test
Classpath: C:\cygwin64\home\latypil\groovytest\build\resources\test
Classpath: C:\cygwin64\home\latypil\groovytest\build\classes\java\main
Classpath: C:\cygwin64\home\latypil\groovytest\build\resources\main
Classpath:
C:\Users\latypil\.gradle\caches\modules-2\files-2.1\org.codehaus.groovy\groovy-all\1.7.6\5f9439657fd8811714db7a7fece9744e63831584\groovy-all-1.7.6.jar
Classpath:
C:\Users\latypil\.gradle\caches\modules-2\files-2.1\junit\junit\4.12\2973d150c0dc1fefe998f834810d68f278ea58ec\junit-4.12.jar
Classpath:
C:\Users\latypil\.gradle\caches\modules-2\files-2.1\org.hamcrest\hamcrest-core\1.3\42a25dc3219429f0e5d060061f71acb49bf010a0\hamcrest-core-1.3.jar
file collection
JUnit version 4.12
.one
E
Time: 1.029
There was 1 failure:
1) testCast(GStringTest)
java.lang.ClassCastException: org.codehaus.groovy.runtime.GStringImpl cannot be
cast to java.lang.String
at GStringTest.testCast(GStringTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at org.junit.runner.JUnitCore.runMain(JUnitCore.java:77)
at org.junit.runner.JUnitCore.main(JUnitCore.java:36)
FAILURES!!!
Tests run: 1, Failures: 1
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':runSimple'.
> Process 'command 'C:\jdk8\bin\java.exe'' finished with non-zero exit value 1
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 11s
2 actionable tasks: 2 executed
{noformat}
> GString cannot be cast to java.lang.String while iterating a collection from
> java
> -
>
> Key: GROOVY-4777
> URL: https://issues.apache.org/jira/browse/GROOVY-4777
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.7.10
> Environment: Linux
>Reporter: David Gomez
>Priority: Major
> Attachments: GStringTest.java, GStringTest.java, build.gradle
>
>
> When i try to iterate a map that contains GStrings i get a
> {noformat}
> java.lang.ClassCastException: org.codehaus.groovy.runtime.GStringImpl cannot
> be cast to java.lang.String
> at experiments.inputdata.GStringCastTest.testCast(GStringCastTest.java:24)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.
[jira] [Commented] (GROOVY-4777) GString cannot be cast to java.lang.String while iterating a collection from java
[
https://issues.apache.org/jira/browse/GROOVY-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577008#comment-16577008
]
Ilguiz Latypov commented on GROOVY-4777:
GString does not (cannot) extend String. It implements CharSequence and has a
toString(),
*
https://github.com/apache/groovy/blob/master/src/main/groovy/groovy/lang/GString.java
but Java Language Specification makes automatic conversion to String via
.toString() possible only with a plus + operator and another String operand. I
doubt one can intercept the implicit casting of a GString object to a String
class (mind that neither compile time nor runtime casting changes the object).
As for why the String class was defined "final" and immutable, I see James
Gosling willing to treat String objects as primitive to preserve their
"identity" and avoid ownership conflicts modifying them without other
references expecting it. (I do not understand why he considered String objects
special in this regard).
* https://www.artima.com/intv/gosling3P.html
> GString cannot be cast to java.lang.String while iterating a collection from
> java
> -
>
> Key: GROOVY-4777
> URL: https://issues.apache.org/jira/browse/GROOVY-4777
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.7.10
> Environment: Linux
>Reporter: David Gomez
>Priority: Major
> Attachments: GStringTest.java
>
>
> When i try to iterate a map that contains GStrings i get a
> {noformat}
> java.lang.ClassCastException: org.codehaus.groovy.runtime.GStringImpl cannot
> be cast to java.lang.String
> at experiments.inputdata.GStringCastTest.testCast(GStringCastTest.java:24)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {noformat}
> Here is the code snippet:
> {code}
> ConfigSlurper slurper = new ConfigSlurper();
> String script =
> "example {\n" +
> " one = \"one\"\n" +
> " two = \"${one} + ${one}\"\n" +
> " three = \"${two} + ${one}\"\n" +
> "}";
> ConfigObject config = slurper.parse(script);
> Map e = (Map) config.get("example");
> for (String k : e.keySet()) {
> String v = e.get(k);
> System.out.println(v);
> }
> {code}
> See attached JUnit test case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: println in "call()" in "vars/xx.groovy" shows in console, but println in defed method in class in "vars/xx.groovy" is just ignored
On Saturday, 11 February 2017 00:49:42 UTC-5, David Karr wrote:
>
> I'm seeing some odd behavior with "println" calls in shared library
> methods, and a perhaps related issue with printing a shared library object
> in a Jenkinsfile.
>
Nice to see an answer to this by Jon S a month later where he suggested to
pass the "this" reference to the "src" class instance (apparently it has an
interface Script). Calling script.echo("...") in a method of that instance
will work. (Without binding to the script object, my bare "echo" in an
"src" instance method resulted in a silent termination of the step).
Jon S also suggested to add a @NonCPS annotation to the "src" instance
methods and declare the "src" class Serializable to allow executing the
method from the context of a slave node.
https://stackoverflow.com/questions/42149652/println-in-call-method-of-vars-foo-groovy-works-but-not-in-method-in-class
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/bf532834-56f4-450b-ade9-3757cc481311%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: accept: Bad address
On Wed, Apr 04, 2018 at 11:25:30AM +0200, Corinna Vinschen wrote: > I reshuffled lots of socket code to make room for a new AF_UNIX > implementation. While at it, I screwed up in a few places, so > socket code was broken for a bit. The OpenSSH testsuite helped > a lot to find the bugs, btw :} > > > Corinna or somebody else with the chops/access, could we get a new Cygwin > > DLL snapshot built when you have a chance? > > New snapshots are up. Thanks, it worked. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
accept: Bad address
Hello, The latest Cygwin 64-bit release with the snapshot cygwin1.dll copied on top of it shows an "accept: Bad address error" in 3 reproducible cases: (a) The sshd daemon on receiving a connection request. (b) The XWin server on receiving a connection request from an X11 client such as xterm. (c) The Python server receiving a TCP connection in the socket's accept(). A StackOverflow question 41018644 from December 2016 showed an example of the bug with the Python server (c). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[jira] [Comment Edited] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov edited comment on TEXT-42 at 10/29/17 4:10 PM:
--
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. Because browsers allow
readable javascript between the script tags, browsers [do not apply a straight
decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code of escapeEcmaScript omitting the
ampersand character from escaping follows this rule and therefore avoids
redundant escaping.
Another decoding still applies and the escaping code appears vulnerable to it.
According to the WHATWG HTML parsing rules, the end script tag will
disrupt javascript parsing in any state. But thanks to LANG-363 in 2007, the
javascript string literal escaping already prevents from injecting the end
script tag by backslash-escaping the forward slash '/'.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
was (Author: ilatypov):
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. Because browsers allow
readable javascript between the script tags, browsers [do not apply a straight
decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code of escapeEcmaScript omitting the
ampersand character from escaping follows this rule and therefore avoids
redundant escaping.
Another decoding still applies and the escaping code appears vulnerable to it.
According to the WHATWG HTML parsing rules, the end script tag will
disrupt javascript parsing in any state. But thanks to LANG-421 in 2008, the
javascript string literal escaping already prevents from injecting the end
script tag by backslash-escaping the forward slash '/'.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
> [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
> --
>
> Key:
[jira] [Comment Edited] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov edited comment on TEXT-42 at 10/29/17 4:06 PM:
--
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. Because browsers allow
readable javascript between the script tags, browsers [do not apply a straight
decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code of escapeEcmaScript omitting the
ampersand character from escaping follows this rule and therefore avoids
redundant escaping.
Another decoding still applies and the escaping code appears vulnerable to it.
According to the WHATWG HTML parsing rules, the end script tag will
disrupt javascript parsing in any state. But thanks to LANG-421 in 2008, the
javascript string literal escaping already prevents from injecting the end
script tag by backslash-escaping the forward slash '/'.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
was (Author: ilatypov):
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. Because browsers allow
readable javascript between the script tags, browsers [do not apply a straight
decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code of escapeEcmaScript omitting the
ampersand character from escaping follows this rule and therefore avoids
redundant escaping.
Another decoding still applies and the escaping code appears vulnerable to it.
According to the WHATWG HTML parsing rules, the end script tag will
disrupt javascript parsing in any state. Changing escapeEcmaScript() to
*escape the less-than character* (with either the backslash-x notation or with
a simple backslash prefix) will prevent from *XSS attacks injecting the end
script tag* . Escaping the greater-than character does not seem
necessary but would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
> [XSS] Possib
[jira] [Comment Edited] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov edited comment on TEXT-42 at 10/29/17 3:53 PM:
--
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. Because browsers allow
readable javascript between the script tags, browsers [do not apply a straight
decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code of escapeEcmaScript omitting the
ampersand character from escaping follows this rule and therefore avoids
redundant escaping.
Another decoding still applies and the escaping code appears vulnerable to it.
According to the WHATWG HTML parsing rules, the end script tag will
disrupt javascript parsing in any state. Changing escapeEcmaScript() to
*escape the less-than character* (with either the backslash-x notation or with
a simple backslash prefix) will prevent from *XSS attacks injecting the end
script tag* . Escaping the greater-than character does not seem
necessary but would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
was (Author: ilatypov):
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. Because browsers allow
readable javascript between the script tags, browsers [stopped applying a
straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code of escapeEcmaScript omitting the
ampersand character from escaping avoids corruption of string literals that
would otherwise be introduced by escaping against non-existent decoding.
Another decoding still applies and the escaping code appears vulnerable to it.
According to the WHATWG HTML parsing rules, the end script tag will
disrupt javascript parsing in any state. Changing escapeEcmaScript() to
*escape the less-than character* (with either the backslash-x notation or with
a simple backslash prefix) will prevent from *XSS attacks injecting the end
script tag* . Escaping the greater-than
[jira] [Comment Edited] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov edited comment on TEXT-42 at 10/29/17 3:50 PM:
--
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. Because browsers allow
readable javascript between the script tags, browsers [stopped applying a
straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code of escapeEcmaScript omitting the
ampersand character from escaping avoids corruption of string literals that
would otherwise be introduced by escaping against non-existent decoding.
Another decoding still applies and the escaping code appears vulnerable to it.
According to the WHATWG HTML parsing rules, the end script tag will
disrupt javascript parsing in any state. Changing escapeEcmaScript() to
*escape the less-than character* (with either the backslash-x notation or with
a simple backslash prefix) will prevent from *XSS attacks injecting the end
script tag* . Escaping the greater-than character does not seem
necessary but would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
was (Author: ilatypov):
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code of escapeEcmaScript omitting the
ampersand character from escaping agrees with the HTML parsers. According to
the WHATWG HTML parsing rules, the end script tag will disrupt
javascript parsing in any state. Changing escapeEcmaScript() to *escape the
less-than character* (with either the backslash-x notation or with a simple
backslash prefix) will prevent from *XSS attacks injecting the end script tag*
. Escaping the greater-than
[jira] [Comment Edited] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov edited comment on TEXT-42 at 10/29/17 3:44 PM:
--
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code of escapeEcmaScript omitting the
ampersand character from escaping agrees with the HTML parsers. According to
the WHATWG HTML parsing rules, the end script tag will disrupt
javascript parsing in any state. Changing escapeEcmaScript() to *escape the
less-than character* (with either the backslash-x notation or with a simple
backslash prefix) will prevent from *XSS attacks injecting the end script tag*
. Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
was (Author: ilatypov):
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either the backslash-x notation or with a
simple backslash prefix). Assuming that browsers may keep applying their HTML
entity decoding throughout the script tag contents, encoding ampersands with
the backslash-x notation or single backslash seems necessary. Escaping the
greater-than character does not seem necessary but would look symmetrical to
escaping the less-than character.
{code:java}
out.println(
[jira] [Comment Edited] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov edited comment on TEXT-42 at 10/29/17 3:29 PM:
--
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either the backslash-x notation or with a
simple backslash prefix). Assuming that browsers may keep applying their HTML
entity decoding throughout the script tag contents, encoding ampersands with
the backslash-x notation or single backslash seems necessary. Escaping the
greater-than character does not seem necessary but would look symmetrical to
escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
was (Author: ilatypov):
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either the backslash-x notation or with a
simple backslash prefix). I suggest to escape ampersands (assuming that
browsers may keep applying their HTML entity decoding throughout the script tag
contents). Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
> [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
>
[jira] [Comment Edited] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov edited comment on TEXT-42 at 10/29/17 3:27 PM:
--
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either the backslash-x notation or with a
simple backslash prefix). I suggest to escape ampersands (assuming that
browsers may keep applying their HTML entity decoding throughout the script tag
contents). Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
was (Author: ilatypov):
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either backslash-x notation or with a
simple backslash prefix). I suggest to escape ampersands (assuming that
browsers may keep applying their HTML entity decoding throughout the script tag
contents). Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
> [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
> -
[jira] [Comment Edited] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov edited comment on TEXT-42 at 10/29/17 3:25 PM:
--
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double quotes seems to be
covered by the existing code in escapeEcmaScript(). We could *extend it to
cover cases of single-quote string literals* and back-quote string templates.
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either backslash-x notation or with a
simple backslash prefix). I suggest to escape ampersands (assuming that
browsers may keep applying their HTML entity decoding throughout the script tag
contents). Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
was (Author: ilatypov):
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double quotes seems to be
covered by the existing code in escapeEcmaScript(). We could extend it to
cover cases of I.e.
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either backslash-x notation or with a
simple backslash prefix). I suggest to escape ampersands (assuming that
browsers may keep applying their HTML entity decoding throughout the script tag
contents). Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
> [XSS] Possib
[jira] [Comment Edited] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov edited comment on TEXT-42 at 10/29/17 3:25 PM:
--
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double or single quotes seems
to be covered by the existing code in escapeEcmaScript().
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either backslash-x notation or with a
simple backslash prefix). I suggest to escape ampersands (assuming that
browsers may keep applying their HTML entity decoding throughout the script tag
contents). Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
was (Author: ilatypov):
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double quotes seems to be
covered by the existing code in escapeEcmaScript(). We could *extend it to
cover cases of single-quote string literals* and back-quote string templates.
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either backslash-x notation or with a
simple backslash prefix). I suggest to escape ampersands (assuming that
browsers may keep applying their HTML entity decoding throughout the script tag
contents). Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
> [XSS] Possible attacks through StringEscapeU
[jira] [Comment Edited] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov edited comment on TEXT-42 at 10/29/17 9:56 AM:
--
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double quotes seems to be
covered by the existing code in escapeEcmaScript(). We could extend it to
cover cases of I.e.
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method *escapeHtmlAttr*. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either backslash-x notation or with a
simple backslash prefix). I suggest to escape ampersands (assuming that
browsers may keep applying their HTML entity decoding throughout the script tag
contents). Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
was (Author: ilatypov):
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double quotes seems to be
covered by the existing code in escapeEcmaScript(). We could extend it to
cover cases of I.e.
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method escapeHtmlAttr. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either backslash-x notation or with a
simple backslash prefix). I suggest to escape ampersands (assuming that
browsers may keep applying their HTML entity decoding throughout the script tag
contents). Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
> [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
&g
[jira] [Commented] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
[
https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223929#comment-16223929
]
Ilguiz Latypov commented on TEXT-42:
I wonder if the escapeEcmaScript()'s use cases can be scrutinized.
* Outputting a standalone javascript file containing string literals. The
generation of string literals to be surrounded by double quotes seems to be
covered by the existing code in escapeEcmaScript(). We could extend it to
cover cases of I.e.
{code:java}
String dq = Character.toString('"');
out.println("alert(" + dq + escapeEcmaScript(input) + dq + ");");
{code}
* Outputting an HTML attribute containing javascript containing string
literals. This needs a new method escapeHtmlAttr. Depending on the
surrounding quotes or absence of them, all characters of the attribute value
will go through either a minimal substitution of [single/double quotes and
ampersand|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(double-quoted)-state]
with the HTML entity or through a broader replacement of [whitespace,
ampersand, single/double quotes, equals, greater/less-than and
backquotes|https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state].
Safety calls to use the broader escaping by default (and allow the narrow one
as an option). I.e.
{code:java}
out.println("onmouseover=" + dq + escapeHtmlAttr("alert(" + dq +
escapeEcmaScript(input) + dq + ")") + dq);
{code}
* Outputting string literals in the script tag contents. The existing code
*lacks protection* against the script's end tag taking precedence over any
contents. Because browsers allow readable javascript between the script tags,
browsers [stopped applying a straight decoding
algorithm|https://stackoverflow.com/questions/41297404/is-it-possible-to-correctly-escape-arbitrary-script-tag-contents]
similar to one in HTML attributes. The code in escapeEcmaScript() *must
escape the less-than character* (with either backslash-x notation or with a
simple backslash prefix). I suggest to escape ampersands (assuming that
browsers may keep applying their HTML entity decoding throughout the script tag
contents). Escaping the greater-than character does not seem necessary but
would look symmetrical to escaping the less-than character.
{code:java}
out.println("alert(" + dq + escapeEcmaScript(input) + dq +
")");
{code}
> [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?
> --
>
> Key: TEXT-42
> URL: https://issues.apache.org/jira/browse/TEXT-42
> Project: Commons Text
> Issue Type: Bug
>Reporter: Andy Reek
> Labels: XSS
> Fix For: 1.x
>
>
> org.apache.commons.lang3.StringEscapeUtils.escapeEcmaScript does the escape
> via a prefixed '\' on all characters which must be escaped. I am not sure if
> this is really secure, if am looking at the comments on
> https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.233_-_JavaScript_Escape_Before_Inserting_Untrusted_Data_into_JavaScript_Data_Values.
> They say it is possible to do an attack by escape the escape. I tested this
> with the string '\"' and the output was '\\\"'. Is this really
> ecma-/java-script secure? Or is it better to use the implementation used by
> OWASP?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-2136) Can't set system directory with derby.system.home for Network Server
[
https://issues.apache.org/jira/browse/DERBY-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000568#comment-15000568
]
Ilguiz Latypov commented on DERBY-2136:
---
Should this be re-opened for the case of the shell script startNetworkServer
executed in Cygwin? The intent of the eval clause appears to parse a
whitespace-separated value DERBY_OPTS into multiple arguments. But this has a
side effect of interpreting the backslash, converting "c:\databases" to
"c:databases".
{code:none}
latypil@MLIW3FZ8G12 /cygdrive/c/db-derby-10.11.1.1-bin/bin
$ DERBY_OPTS='-Dderby.system.home=c:\databases' bash -x startNetworkServer
[..]
+ derby_exec_command='exec "/cygdrive/c/ProgramData/Oracle/Java/javapath/java"
-Dderby.system.home=c:\databases -classpath
"C:/db-derby-10.11.1.1-bin/lib/derby.jar;C:/db-derby-10.11.1.1-bin/lib/derbynet.jar;C:/db-derby-10.11.1.1-bin/lib/derbytools.jar;C:/db-derby-10.11.1.1-bin/lib/derbyclient.jar"
org.apache.derby.drda.NetworkServerControl start '
+ eval exec '"/cygdrive/c/ProgramData/Oracle/Java/javapath/java"'
'-Dderby.system.home=c:\databases' -classpath
'"C:/db-derby-10.11.1.1-bin/lib/derby.jar;C:/db-derby-10.11.1.1-bin/lib/derbynet.jar;C:/db-derby-10.11.1.1-bin/lib/derbytools.jar;C:/db-derby-10.11.1.1-bin/lib/derbyclient.jar"'
org.apache.derby.drda.NetworkServerControl start
++ exec /cygdrive/c/ProgramData/Oracle/Java/javapath/java
-Dderby.system.home=c:databases -classpath
'C:/db-derby-10.11.1.1-bin/lib/derby.jar;C:/db-derby-10.11.1.1-bin/lib/derbynet.jar;C:/db-derby-10.11.1.1-bin/lib/derbytools.jar;C:/db-derby-10.11.1.1-bin/lib/derbyclient.jar'
org.apache.derby.drda.NetworkServerControl start
Wed Nov 11 10:33:24 EST 2015 : Security manager installed using the Basic
server security policy.
Wed Nov 11 10:33:25 EST 2015 : Apache Derby Network Server - 10.11.1.1 -
(1616546) started and ready to accept connections on port 1527
{code}
The following patch works for me.
{code:none}
--- startNetworkServer.orig 2015-08-19 10:18:40.858650900 -0400
+++ startNetworkServer 2015-11-11 10:56:03.271674100 -0500
@@ -137,54 +137,18 @@
CYGHOME=`cygpath --$format "$HOME"`
fi
-# add a second backslash to variables terminated by a backslash under cygwin
-if $cygwin; then
- case "$DERBY_HOME" in
-*\\ )
-DERBY_HOME="$DERBY_HOME\\"
-;;
- esac
- case "$CYGHOME" in
-*\\ )
-CYGHOME="$CYGHOME\\"
-;;
- esac
- case "$LOCALCLASSPATH" in
-*\\ )
-LOCALCLASSPATH="$LOCALCLASSPATH\\"
-;;
- esac
- case "$CLASSPATH" in
-*\\ )
-CLASSPATH="$CLASSPATH\\"
-;;
- esac
-fi
-
# Readjust classpath for MKS
# expr match
if [ \( "`expr $SHELL : '.*sh.exe$'`" -gt 0 \) -a \( "$cygwin" = "false" \) ];
then
LOCALCLASSPATH=`echo $LOCALCLASSPATH | sed -E 's/([\d\w]*):([\d\w]*)/\1;\2/g
'`
fi
-#!/bin/sh
-
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-
-# http://www.apache.org/licenses/LICENSE-2.0
-
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-derby_exec_command="exec \"$JAVACMD\" $DERBY_OPTS -classpath
\"$LOCALCLASSPATH\" org.apache.derby.drda.NetworkServerControl start $@"
-eval $derby_exec_command
+# Unlike Bash variable assignments, double quotes in the exec line preserve the
+# content from word expansion. We keep JAVACMD, LOCALCLASSPATH as single
+# words. We expand DERBY_OPTS into possibly multiple words. We could expand
+# DERBY_OPTS beforehand with derby_opts_array=($DERBY_OPTS) and then let shell
+# expand the array notation "${derby_opts_array[@]}" into words. The "$@"
+# construct expands this script's arguments into multiple words similarly to
+# the array notation "${var[@]}".
+exec "$JAVACMD" $DERBY_OPTS -classpath "$LOCALCLASSPATH"
org.apache.derby.drda.NetworkServerControl start "$@"
{code}
The trace of the script shows preserved back-slashes,
{code:none}
+ exec /cygdrive/c/ProgramData/Oracle/Java/javapath/java
'-Dderby.system.home=c:\databases' -classpath
'C:/db-derby-10.11.1.1-bin/lib/derby.jar;C:/db-derby-10.11.1.1-
[jira] [Created] (IO-476) FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date
Ilguiz Latypov created IO-476: - Summary: FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date Key: IO-476 URL: https://issues.apache.org/jira/browse/IO-476 Project: Commons IO Issue Type: Test Reporter: Ilguiz Latypov Priority: Minor The test FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date failed in a nightly run of our tests that needed an arbitrary project such as Apache's Commons IO to work against. I suspect that the failure resulted from a system time adjustment taking place between the instantiation of the Date() object and creating a new file where its time stamp has to differ from one of a reference file, https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987 Since system time lacks guaranteed continuity, the tests could stabilize by dropping the use of the current time and stopping the assumption that any unequal time stamp as the code progresses turns larger than the one we compare against. (a) The tests against the current time stamps created with Date() could stabilize by making sure that these time stamps grew larger than the reference stamp and by making sure that every subsequent file stamp and system time reading has a value larger than before. (b) The wait for unequal time stamps could stabilize by waiting for the stamp value that outgrows the reference one. This will make the tests all the more trivial and less useful. Having a guaranteed continuous time source could make them substantial. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-476) FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date
[ https://issues.apache.org/jira/browse/IO-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilguiz Latypov updated IO-476: -- Description: The test FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date failed in a nightly run of our tests that needed an arbitrary project such as Apache's Commons IO to work against. I suspect that the failure resulted from a system time adjustment taking place between the instantiation of the Date() object and creating a new file where its time stamp has to differ from one of a reference file, https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987 Since system time lacks guaranteed continuity, the tests could stabilize by dropping the use of the current time and stopping the assumption that any unequal time stamp as the code progresses turns larger than the one we compare against. (a) The tests against the current time stamps created with Date() could stabilize by making sure that these time stamps grew larger than the reference stamp and by making sure that every subsequent file stamp and system time reading has a value larger than before. (b) The wait for unequal time stamps could stabilize by waiting for the stamp value that outgrows the reference one. This will make the tests all the more trivial and less useful. Having a guaranteed continuous time source could make them substantial. Not sure if JVM's re-ordering the instructions could de-stabilize tests that connect to the file system and the desired continuous time source. was: The test FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date failed in a nightly run of our tests that needed an arbitrary project such as Apache's Commons IO to work against. I suspect that the failure resulted from a system time adjustment taking place between the instantiation of the Date() object and creating a new file where its time stamp has to differ from one of a reference file, https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987 Since system time lacks guaranteed continuity, the tests could stabilize by dropping the use of the current time and stopping the assumption that any unequal time stamp as the code progresses turns larger than the one we compare against. (a) The tests against the current time stamps created with Date() could stabilize by making sure that these time stamps grew larger than the reference stamp and by making sure that every subsequent file stamp and system time reading has a value larger than before. (b) The wait for unequal time stamps could stabilize by waiting for the stamp value that outgrows the reference one. This will make the tests all the more trivial and less useful. Having a guaranteed continuous time source could make them substantial. FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date -- Key: IO-476 URL: https://issues.apache.org/jira/browse/IO-476 Project: Commons IO Issue Type: Test Reporter: Ilguiz Latypov Priority: Minor Labels: test The test FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date failed in a nightly run of our tests that needed an arbitrary project such as Apache's Commons IO to work against. I suspect that the failure resulted from a system time adjustment taking place between the instantiation of the Date() object and creating a new file where its time stamp has to differ from one of a reference file, https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987 Since system time lacks guaranteed continuity, the tests could stabilize by dropping the use of the current time and stopping the assumption that any unequal time stamp as the code progresses turns larger than the one we compare against. (a) The tests against the current time stamps created with Date() could stabilize by making sure that these time stamps grew larger than the reference stamp and by making sure that every subsequent file stamp and system time reading has a value larger than before. (b) The wait for unequal time stamps could stabilize by waiting for the stamp value that outgrows the reference one. This will make the tests all the more trivial and less useful. Having a guaranteed continuous time source could make them substantial. Not sure if JVM's re-ordering the instructions could de-stabilize tests that connect to the file system and the desired continuous time source. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Bug#705251: smbclient -L produces suspicious DNS lookup failures in log.nmbd
Package: smbclient Version: 2:3.6.13-1 Severity: minor Dear Maintainer, * What led up to the situation? Ran smbclient -A /etc/credentials-USER -L HOST.example.net * What exactly did you do (or not do) that was effective (or ineffective)? Ran the above command. * What was the outcome of this action? The list of shares showed up with a harmless NT_STATUS_CONNECTION_RESET message in the bottom. read_fd_with_timeout failed, read error = NT_STATUS_CONNECTION_RESET. Receiving SMB: Server 10.65.25.54 stopped responding session request to HOST.EXAMPLE.NET failed (Read error: Connection reset by peer) The log file /var/log/samba/log.nmbd had this, [2013/04/11 19:15:09, 3] nmbd/nmbd_winsserver.c:2068(wins_process_name_query_request) wins_process_name_query: name query for name HOST.EXAMPLE.NE20 returning DNS fail. My /etc/request-key.conf has my correction against a dns_resolver from /sbin/key.dns_resover that worked around mounting DFS shares, #create dns_resolver * * /sbin/key.dns_resolver %k create userdebug:* negate /bin/keyctl negate %k 30 %S create userdebug:* rejected/bin/keyctl reject %k 30 %c %S create userdebug:* expired /bin/keyctl reject %k 30 %c %S create userdebug:* revoked /bin/keyctl reject %k 30 %c %S create userdebug:loop:** |/bin/cat create userdebug:* * /usr/share/keyutils /request-key-debug.sh %k %d %c %S # Follow a separate entry in /etc/request-key.d/ #create cifs.spnego * * /usr/sbin/cifs.upcall -t %k # Do not follow man cifs.upcall suggesting to prefer key.dns_resolver to # cifs.upcall as the former receives -126 from a call to # keyctl_instantiate_iov(). create dns_resolver* * /usr/sbin/cifs.upcall -t %k negate * * * /bin/keyctl negate %k 30 %S I kept another option in a separate file /etc/request- key.d/cifs.spnego.conf, create cifs.spnego* * /usr/sbin/cifs.upcall -t %k Running the same command against the short hostname HOST produced same list without the message. I have the recommended version of cifs-utils, $ dpkg -S /usr/sbin/cifs.upcall cifs-utils: /usr/sbin/cifs.upcall $ dpkg -l cifs-utils Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig- pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersionArchitecture Description +++-===-==-==-=== ii cifs-utils 2:5.5-1i386 Common Internet File System utilities * What outcome did you expect instead? No reset message, no suspicious DNS lookups. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages smbclient depends on: ii dpkg 1.16.10 ii libc6 2.13-38 ii libcap2 1:2.22-1.2 ii libcomerr21.42.5-1.1 ii libgssapi-krb5-2 1.10.1+dfsg-5 ii libk5crypto3 1.10.1+dfsg-5 ii libkrb5-3 1.10.1+dfsg-5 ii libldap-2.4-2 2.4.31-1 ii libpopt0 1.16-7 ii libreadline6 6.2+dfsg-0.1 ii libtalloc22.0.8-0.1 ii libtdb1 1.2.10-2 ii libtinfo5 5.9-10 ii libwbclient0 2:3.6.13-1 ii samba-common 2:3.6.13-1 ii zlib1g1:1.2.7.dfsg-13 smbclient recommends no packages. Versions of packages smbclient suggests: ii cifs-utils 2:5.5-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691093: /sbin/dosfsck: Re: /sbin/dosfsck: fsck.msdos with -a terminates with buffer overflow detected
Package: dosfstools Version: 3.0.13-1 Followup-For: Bug #691093 Dear Maintainer, Same here. * What led up to the situation? Checking the filesystem of a micro SD card. * What exactly did you do (or not do) that was effective (or ineffective)? I ran sudo fsck /dev/sdc1 -a. * What was the outcome of this action? A crash dump referring to a buffer overflow detected by fortify. * What outcome did you expect instead? Fixing the file system. $ sudo fsck /dev/sdc1 -a fsck from util-linux 2.20.1 dosfsck 3.0.13, 30 Jun 2012, FAT32, LFN *** buffer overflow detected ***: fsck.vfat terminated === Backtrace: = /lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xb766a3c0] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe92fa)[0xb76692fa] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe8a38)[0xb7668a38] /lib/i386-linux-gnu/i686/cmov/libc.so.6(_IO_default_xsputn+0x9e)[0xb75ef47e] /lib/i386-linux-gnu/i686/cmov/libc.so.6(_IO_vfprintf+0xef4)[0xb75c0954] /lib/i386-linux-gnu/i686/cmov/libc.so.6(__vsprintf_chk+0xa7)[0xb7668ae7] /lib/i386-linux-gnu/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xb7668a2d] fsck.vfat[0x804c8d4] === Memory map: 08048000-08055000 r-xp 08:11 8650815/sbin/dosfsck 08055000-08056000 r--p c000 08:11 8650815/sbin/dosfsck 08056000-08057000 rw-p d000 08:11 8650815/sbin/dosfsck 08057000-08059000 rw-p 00:00 0 09bf5000-09c34000 rw-p 00:00 0 [heap] b74c9000-b74e5000 r-xp 08:11 5785914/lib/i386-linux- gnu/libgcc_s.so.1 b74e5000-b74e6000 rw-p 0001b000 08:11 5785914/lib/i386-linux- gnu/libgcc_s.so.1 b7505000-b758 rw-p 00:00 0 b758-b76dc000 r-xp 08:11 5921995/lib/i386-linux- gnu/i686/cmov/libc-2.13.so b76dc000-b76dd000 ---p 0015c000 08:11 5921995/lib/i386-linux- gnu/i686/cmov/libc-2.13.so b76dd000-b76df000 r--p 0015c000 08:11 5921995/lib/i386-linux- gnu/i686/cmov/libc-2.13.so b76df000-b76e rw-p 0015e000 08:11 5921995/lib/i386-linux- gnu/i686/cmov/libc-2.13.so b76e-b76e3000 rw-p 00:00 0 b7701000-b7704000 rw-p 00:00 0 b7704000-b7705000 r-xp 00:00 0 [vdso] b7705000-b7721000 r-xp 08:11 5788479/lib/i386-linux-gnu/ld-2.13.so b7721000-b7722000 r--p 0001b000 08:11 5788479/lib/i386-linux-gnu/ld-2.13.so b7722000-b7723000 rw-p 0001c000 08:11 5788479/lib/i386-linux-gnu/ld-2.13.so bfd76000-bfd97000 rw-p 00:00 0 [stack] fsck: Warning... fsck.vfat for device /dev/sdc1 exited with signal 6. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.5-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dosfstools depends on: ii libc6 2.13-37 dosfstools recommends no packages. dosfstools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691093: a work-around
Running dosfsck -r PARTITION works around the crash. -- - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679319: a work-around
On 27/06/12 07:57 PM, Ilguiz Latypov wrote: I worked around the crash by choosing Open JDK 1.7 to run davmail compiled by Open JDK 1.6. sudo update-alternatives --config java After reporting my work-around I followed advice of the davmail author and disabled the use of system proxy settings in the davmail setup dialog. I then switched the default Java runtime to Open JDK 1.6 and found that davmail could start without a crash. -- - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679319: a work-around
I worked around the crash by choosing Open JDK 1.7 to run davmail compiled by Open JDK 1.6. sudo update-alternatives --config java I believe it is possible that davmail could compile with Open JDK 1.7 and that its build system prevents higher version numbers by mistake. I believe changing the Java runtime might hide the defect. I did not investigate the root cause of the defect. Perhaps, the libraries shown by the traces only receive a corruption from JDK. -- - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679319: a work-around
On 27/06/12 07:57 PM, Ilguiz Latypov wrote: I worked around the crash by choosing Open JDK 1.7 to run davmail compiled by Open JDK 1.6. sudo update-alternatives --config java After reporting my work-around I followed advice of the davmail author and disabled the use of system proxy settings in the davmail setup dialog. I then switched the default Java runtime to Open JDK 1.6 and found that davmail could start without a crash. -- - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679319: a work-around
I worked around the crash by choosing Open JDK 1.7 to run davmail compiled by Open JDK 1.6. sudo update-alternatives --config java I believe it is possible that davmail could compile with Open JDK 1.7 and that its build system prevents higher version numbers by mistake. I believe changing the Java runtime might hide the defect. I did not investigate the root cause of the defect. Perhaps, the libraries shown by the traces only receive a corruption from JDK. -- - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Cannot start Bash after today's update
C:\Users\USER\cygwin\bin\bash.exe 0 [main] bash 6784 C:\cygwin\bin\bash.exe: *** fatal error - add_item (㽜尿㩃捜杹楷n, /, ...) failed, errno 1 Stack trace: Frame Function Args 002888D8 6102F96B (002888D8, , , ) 00288BC8 6102F96B (6119BD20, 8000, , 6119DB0F) 00289BF8 61005F0C (611D7FC0, 00289C24, , 60FE000C) 00289C18 61005F48 (611D7FC0, 0028BC40, 0001, 0003000A) 0028CC58 6108FB97 (60FE000C, 2264, 0028CD28, 610818C0) 0028CC88 610D14EF (CD0A5162, 01CCE5BB, 004657E0, 61264968) End of stack trace -- - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Cannot start Bash after today's update
This looks very strange, almost impossible. Did you still have Cygwin processes running, services maybe, while you updated? Indeed, I forgot to stop cygrunsrv and sshd. When I saw your question I ran ProcessExplorer64, turned on the view of all processes but could not find cygrunsrv, sshd or anything using cyg DLLs. When I ran bash again, it worked. Thanks for the hint. -- - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: hard-coded library search path in gcc-4
$ ( export PATH= ; /cygdrive/c/cygwin/bin/gcc-4.exe -v -E - /dev/null ) I figured that cc1 depends on /usr/bin. A user invoking cc1 directly could figure the missing dependency. Invoking cc1 indirectly from /usr/bin/gcc-4 without /usr/bin in PATH will break cc1 against expectation of /usr/bin/gcc-4 passing its containing directory to cc1 as a library search directory. $ cygcheck /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe C:\cygwin\lib\gcc\i686-pc-cygwin\4.5.3\cc1.exe C:\cygwin\bin\cygcloog-0.dll C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cyggmp-3.dll C:\cygwin\bin\cygppl_c-2.dll C:\cygwin\bin\cygppl-7.dll C:\cygwin\bin\cygstdc++-6.dll C:\cygwin\bin\cyggmpxx-4.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygintl-8.dll C:\cygwin\bin\cygmpc-1.dll C:\cygwin\bin\cygmpfr-1.dll C:\cygwin\bin\cygmpfr-4.dll C:\cygwin\bin\cygz.dll $ PATH= /usr/bin/cygcheck /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe C:\cygwin\lib\gcc\i686-pc-cygwin\4.5.3\cc1.exe C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll cygcheck: WARNING: PATH is not set cygcheck: track_down: could not find cygcloog-0.dll cygcheck: track_down: could not find cygwin1.dll cygcheck: track_down: could not find cyggmp-3.dll cygcheck: track_down: could not find cygiconv-2.dll cygcheck: track_down: could not find cygintl-8.dll cygcheck: track_down: could not find cygmpc-1.dll cygcheck: track_down: could not find cygmpfr-4.dll cygcheck: track_down: could not find cygppl_c-2.dll cygcheck: track_down: could not find cygz.dll Cheers. -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
hard-coded library search path in gcc-4
I found that gcc-4 from a recent setup.exe could not start cc1 because the latter could not find some shared object file. I confirmed that by running cc1 alone with an empty PATH variable. $ ( export PATH= ; /cygdrive/c/cygwin/bin/gcc-4.exe -v -E - /dev/null ) Using built-in specs. COLLECT_GCC=/cygdrive/c/cygwin/bin/gcc-4 COLLECT_LTO_WRAPPER=/cygdrive/c/cygwin/bin/../lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure --srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enable-lto --enable-java-awt=gtk --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.5.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=i686' /cygdrive/c/cygwin/bin/../lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe -E -quiet -v -iprefix /cygdrive/c/cygwin/bin/../lib/gcc/i686-pc-cygwin/4.5.3/ -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/../include/w32api -idirafter ../../include/w32api - -mtune=generic -march=i686 /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory $ /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe -o /dev/null - /dev/null Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups whole-program inlineAssembling functions: Execution times (seconds) TOTAL : 0.00 0.00 0.01 590 kB $ PATH= /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe -o /dev/null - /dev/null /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory Cheers! -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug#652092: Gnash does not handle --enable-avm2
Package: gnash Version: 0.8.10 The --enable-avm2 option causes a warning in the configure script saying that the script did not recognize the option. I found that configure.ac commented out its handling by putting dnl at the beginning of each line. Removing the dnl (delete to new line?) words and removing the build directory gnash-0.8.10~git.master21430, then running make deb resulted in a build break, CXX DefaultTagLoaders.lo /bin/bash ../libtool --silent --tag=CXX --mode=compile i486-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore -I.. -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/librender -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libdevice -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/swf -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/abc -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/asobj -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/asobj/flash -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/parser -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/vm -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libltdl -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libbase -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libmedia -I/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libsound -pthread -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -W -Wall -Wcast-align -Wcast-qual -Wpointer-arith -Wreturn-type -Wnon-virtual-dtor -Wunused -fvisibility-inlines-hidden -c -o DefaultTagLoaders.lo `test -f 'swf/DefaultTagLoaders.cpp' || echo '/home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/'`swf/DefaultTagLoaders.cpp In file included from /home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/swf/DefaultTagLoaders.cpp:59:0: /home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/swf/SymbolClassTag.h: In member function 'virtual void gnash::SWF::SymbolClassTag::executeActions(gnash::MovieClip*, gnash::DisplayList) const': /home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/swf/SymbolClassTag.h:48:33: error: 'class gnash::VM' has no member named 'getMachine' In file included from /home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/swf/DefaultTagLoaders.cpp:60:0: /home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/swf/DoABCTag.h: In member function 'virtual void gnash::SWF::DoABCTag::executeActions(gnash::MovieClip*, gnash::DisplayList) const': /home/ilguiz/gnash/gnash-0.8.10~git.master21430/libcore/swf/DoABCTag.h:56:33: error: 'class gnash::VM' has no member named 'getMachine' make[6]: *** [DefaultTagLoaders.lo] Error 1 make[6]: Leaving directory `/home/ilguiz/gnash/gnash-0.8.10~git.master21430/_build/libcore' It seems that the handling of the option was put away because it did not follow later changes in the code and/or did not agree with those changes. So I guess addining the --enable-avm2 option to debian/rules did not enable AVM2, and my tests on a flash web site confirm that. I tried lightspark, but it gave Unsupported ActionScript exception on the yet unsupported Flash file, http://www.rogersondemand.com/f/hero.swf?ver=2.9.5.13 I wonder if the description of gnash could refer to lightspark as the package extending capabilities of gnash. -- ilguiz - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645210: debian-installer: grub2 setup for a new drive misses a Windows boot choice from the original drive
Package: debian-installer Version: i386 netinst as of October 5, 2011 Severity: important Tags: d-i Dear Maintainer, * What led up to the situation? I decided to install Debian on a new disk drive and preserve the Windows installation on the original drive. I downloaded the latest i386 netinst ISO image of Debian Installer, burned it on a DVD and booted off it. * What exactly did you do (or not do) that was effective (or ineffective)? I chose the new drive for simple partitioning. I chose to install Grub2 in MBR of the original drive. * What was the outcome of this action? I did not see Windows as a boot option. (This took a worse turn when the udev in the initial RAM disk image loaded a kernel module radeon for my video card ATI Radeon HD 3600, apparently in an attempt to provide a frame buffer for the text mode, and the video card showed garbage. It took a while to add an option blacklist=radeon to the kernel command line at boot time and add a line blacklist radeon to a file in /etc/modprobe.d). * What outcome did you expect instead? I expected to see a boot option to start from a partition in the original disk drive. Here is how I worked around the issue. I booted off the netinst DVD into a rescue mode. Ran update-grub and it did not show the Windows partition of the original drive. Inspected the output of os-prober. I believe it did not show Windows either. I then ran fdisk -l and I think I saw my original disk drive with its Windows partition. After inspecting os-prober I figured it depended on the list of mounted partitions. I added the Windows partition to /etc/fstab, /dev/sda1 /c ntfsauto0 0 Unfortunately, mount /c failed because the target root partition where I chrooted did not have modules of the rescue kernel. I cannot remember how I succeeded in mounting the partition before re-running update-grub. Perhaps, I returned or rebooted to the dialogs of the rescue mode of Debian Installer and chose to re-configure Grub2 in the dialogs. I could see my Windows partition of the original drive in the bootloader's list at boot time. I could successfully start Windows. Here is my opinion on a possible root cause. It seems that Debian Installer does not attempt to mount partitions on drives other than the one selected for partitioning. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645210: debian-installer: grub2 setup for a new drive misses a Windows boot choice from the original drive
Package: debian-installer Version: i386 netinst as of October 5, 2011 Severity: important Tags: d-i Dear Maintainer, * What led up to the situation? I decided to install Debian on a new disk drive and preserve the Windows installation on the original drive. I downloaded the latest i386 netinst ISO image of Debian Installer, burned it on a DVD and booted off it. * What exactly did you do (or not do) that was effective (or ineffective)? I chose the new drive for simple partitioning. I chose to install Grub2 in MBR of the original drive. * What was the outcome of this action? I did not see Windows as a boot option. (This took a worse turn when the udev in the initial RAM disk image loaded a kernel module radeon for my video card ATI Radeon HD 3600, apparently in an attempt to provide a frame buffer for the text mode, and the video card showed garbage. It took a while to add an option blacklist=radeon to the kernel command line at boot time and add a line blacklist radeon to a file in /etc/modprobe.d). * What outcome did you expect instead? I expected to see a boot option to start from a partition in the original disk drive. Here is how I worked around the issue. I booted off the netinst DVD into a rescue mode. Ran update-grub and it did not show the Windows partition of the original drive. Inspected the output of os-prober. I believe it did not show Windows either. I then ran fdisk -l and I think I saw my original disk drive with its Windows partition. After inspecting os-prober I figured it depended on the list of mounted partitions. I added the Windows partition to /etc/fstab, /dev/sda1 /c ntfsauto0 0 Unfortunately, mount /c failed because the target root partition where I chrooted did not have modules of the rescue kernel. I cannot remember how I succeeded in mounting the partition before re-running update-grub. Perhaps, I returned or rebooted to the dialogs of the rescue mode of Debian Installer and chose to re-configure Grub2 in the dialogs. I could see my Windows partition of the original drive in the bootloader's list at boot time. I could successfully start Windows. Here is my opinion on a possible root cause. It seems that Debian Installer does not attempt to mount partitions on drives other than the one selected for partitioning. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111013153103.12733.6194.report...@ilatypov.rim.net
Bug#622828: recovery
Contrary to my earlier conclusion, the upgrade did not delete older images. It appears a ramdisk generation change may have included a bad module whose loading crashed the system later. I could not boot other images because my Grub 2 configuration file grub.cfg missed the corresponding initrd lines. The latter were missing probably because of a ramdisk generation failure. This resulted in a cryptic error message at the boot failure about inability to find a root filesystem in a certain (0,0) disk. As I mentioned earlier, after loading to a shell prompt by editing the linux line in grub boot screen and adding init=/bin/bash, I could disable swapping with swapoff -a, remount the root partition in a read-write mode and start networking. This allowed me to update packages in aptitude. I also had to boot off a recent Debian installer CD-R disk, http://cdimage.debian.org/cdimage/daily-builds/unstable/current/i386/iso-cd/ because I did not understand the reason for the (0,0) root disk mount crash. I also suspect that my manual invocation of update-initramfs failed to include all required modules. In the end, I dropped to shell from the rescue disk, mounted my root filesystem with mount -t ext3 /dev/sda1 /mnt and changed to it with chroot /mnt. I then re-generated the initial ramdisk images with update-initramfs -k 2.6.32-5-686 -d update-initramfs -k 2.6.32-5-686 -c and same commands for some other kernel versions. This allowed me to boot my system in full with 2.6.32-5-686 which turned to be the original kernel version that worked long time for me. (The newer 2.6.38..-686 kernel on which 2.6-686 depends crashes in the Wi-Fi module mac80211 calling a function in cfg80211 when I attempt to associate with my Wi-Fi router. I logged that issue under bug #622833). Still, I do not understand how possible differences in update-initramfs could cause a libata kernel crash. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622828: recovery
Contrary to my earlier conclusion, the upgrade did not delete older images. It appears a ramdisk generation change may have included a bad module whose loading crashed the system later. I could not boot other images because my Grub 2 configuration file grub.cfg missed the corresponding initrd lines. The latter were missing probably because of a ramdisk generation failure. This resulted in a cryptic error message at the boot failure about inability to find a root filesystem in a certain (0,0) disk. As I mentioned earlier, after loading to a shell prompt by editing the linux line in grub boot screen and adding init=/bin/bash, I could disable swapping with swapoff -a, remount the root partition in a read-write mode and start networking. This allowed me to update packages in aptitude. I also had to boot off a recent Debian installer CD-R disk, http://cdimage.debian.org/cdimage/daily-builds/unstable/current/i386/iso-cd/ because I did not understand the reason for the (0,0) root disk mount crash. I also suspect that my manual invocation of update-initramfs failed to include all required modules. In the end, I dropped to shell from the rescue disk, mounted my root filesystem with mount -t ext3 /dev/sda1 /mnt and changed to it with chroot /mnt. I then re-generated the initial ramdisk images with update-initramfs -k 2.6.32-5-686 -d update-initramfs -k 2.6.32-5-686 -c and same commands for some other kernel versions. This allowed me to boot my system in full with 2.6.32-5-686 which turned to be the original kernel version that worked long time for me. (The newer 2.6.38..-686 kernel on which 2.6-686 depends crashes in the Wi-Fi module mac80211 calling a function in cfg80211 when I attempt to associate with my Wi-Fi router. I logged that issue under bug #622833). Still, I do not understand how possible differences in update-initramfs could cause a libata kernel crash. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110422135659.ga5...@ei.homeip.net
Bug#622828: corrected
Thanks for quashing my hasty conclusion about the timing of the kernel crash. I now see that the crash occurred after the ramdisk stage succeeded. Probably, this may have something to do with memory paging to disk. I could boot to the shell, disable swapping, launch udev, resolvconf, dnsmasq, networking, submit the bug, update packages with aptitude. I could not find a work-around. I cannot remember the version of my last successful image as the upgrade deleted it. Perhaps, I can look up my logs to find the version. My online search showed only the current unstable and stable packages, both of which failed to boot for different reasons. The earlier (oldstable?) package 2.6.26 bailed to a ramdisk shell prompt after failing to run a newer udev daemon. Perhaps, the package information for that earlier image could require a ramdisk make tool and/or ramdisk components relevant to that version. I sent screenshots of the stack trace just before receiving your email requesting them. I see the screen shots in the log of this bug report. Cheers. --
Bug#622828: corrected
Thanks for quashing my hasty conclusion about the timing of the kernel crash. I now see that the crash occurred after the ramdisk stage succeeded. Probably, this may have something to do with memory paging to disk. I could boot to the shell, disable swapping, launch udev, resolvconf, dnsmasq, networking, submit the bug, update packages with aptitude. I could not find a work-around. I cannot remember the version of my last successful image as the upgrade deleted it. Perhaps, I can look up my logs to find the version. My online search showed only the current unstable and stable packages, both of which failed to boot for different reasons. The earlier (oldstable?) package 2.6.26 bailed to a ramdisk shell prompt after failing to run a newer udev daemon. Perhaps, the package information for that earlier image could require a ramdisk make tool and/or ramdisk components relevant to that version. I sent screenshots of the stack trace just before receiving your email requesting them. I see the screen shots in the log of this bug report. Cheers. --
Bug#622828: linux-image-2.6.32-5-686: kernel panic mentions libata in the stack trace
Package: linux-2.6 Version: 2.6.32-30 Severity: critical Justification: breaks the whole system Both normal and safe boot modes panicked when running the ram disk image. Worse, the upgrade DELETED the earlier kernel image and ram disk image. I managed to boot by editing the safe mode command line and adding the option init=/bin/bash. When the kernel panicks, it shows a stack trace mentioning libata. -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-30) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 12 04:01:41 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=281d76c7-ee09-4f0e-825b-425e95d75878 ro single init=/bin/bash ** Not tainted ** Kernel log: [3.331507] PM: Checking hibernation image. [3.331689] PM: Error -22 checking image file [3.331692] PM: Resume from disk failed. [3.338369] PM: Marking nosave pages: 0009f000 - 0010 [3.338378] PM: Basic memory bitmaps created [3.345712] PM: Basic memory bitmaps freed [3.372024] usb 2-1: new full speed USB device using ohci_hcd and address 2 [3.401886] kjournald starting. Commit interval 5 seconds [3.401897] EXT3-fs: mounted filesystem with ordered data mode. [3.568751] usb 2-1: New USB device found, idVendor=03f0, idProduct=0517 [3.568808] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.568857] usb 2-1: Product: hp LaserJet 1000 [3.568903] usb 2-1: Manufacturer: Hewlett-Packard [3.569118] usb 2-1: configuration #1 chosen from 1 choice [7.505287] usb-storage: device scan complete [7.506404] scsi 6:0:0:0: Direct-Access RIM BlackBerry SD0003 PQ: 0 ANSI: 4 CCS [7.507080] sd 6:0:0:0: Attached scsi generic sg2 type 0 [7.508515] sd 6:0:0:0: [sdb] Attached SCSI removable disk [ 184.561988] EXT3 FS on sda1, internal journal [ 1241.810372] 30udev[382]: starting version 167 [ 1242.505471] 30udev[405]: renamed network interface eth0 to tp [ 1243.710686] input: PC Speaker as /devices/platform/pcspkr/input/input2 [ 1244.157244] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1244.250681] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input3 [ 1244.250866] ACPI: Power Button [PWRB] [ 1244.251036] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4 [ 1244.251271] ACPI: Power Button [PWRF] [ 1244.613408] processor LNXCPU:00: registered as cooling_device0 [ 1244.614971] processor LNXCPU:01: registered as cooling_device1 [ 1244.619420] usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x03F0 pid 0x0517 [ 1244.619503] usbcore: registered new interface driver usblp [ 1244.625601] parport_pc 00:06: reported by Plug and Play ACPI [ 1244.627407] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] [ 1244.639042] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 1245.015484] ali1535_smbus :00:1e.1: ALI1535_smb region uninitialized - upgrade BIOS? [ 1245.015576] ali1535_smbus :00:1e.1: ALI1535 not detected, module not inserted. [ 1245.025103] ali15x3_smbus :00:1e.1: ALI15X3_smb region uninitialized - upgrade BIOS or use force_addr=0xaddr [ 1245.025165] ali15x3_smbus :00:1e.1: ALI15X3 not detected, module not inserted. [ 1245.089649] alim7101_wdt: Steve Hill st...@navaho.co.uk. [ 1245.089710] alim7101_wdt: ALi 1543 South-Bridge not present - WDT not set [ 1245.404977] cfg80211: Using static regulatory domain info [ 1245.405031] cfg80211: Regulatory domain: US [ 1245.405076] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 1245.405130] (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) [ 1245.405178] (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405226] (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405274] (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405322] (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405369] (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [ 1245.405922] cfg80211: Calling CRDA for country: US [ 1245.609148] adm8211 :03:11.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 1245.619583] :03:11.0 (adm8211): Channel range: 1 - 11 [ 1245.619588] :03:11.0 (adm8211): RFtype=1 BBPtype=1 Specific BBP=0 Transceiver=0 [ 1246.177701] phy0: Selected rate control algorithm 'minstrel' [ 1246.178756] phy0: hwaddr 00:04:e2:7b:70:6b, Rev 0x11 [ 1246.189113] 30udev[403]: renamed network interface wlan0 to wl [ 1246.938086] HDA Intel :00:1d.0: PCI INT C - GSI 22 (level, low) - IRQ 22 [ 1246.938155] hda_intel: position_fix set to 1 for device 1043:81b3 [ 1247.383775] input: HDA Digital PCBeep as /devices/pci:00/:00:1d.0/input/input5 [ 1252.897954] usblp0: removed [ 1323.238716] r8169: tp: link down [ 1323.238987] ADDRCONF(NETDEV_UP): tp: link is not ready [ 1332.520717] ADDRCONF(NETDEV_UP): wl: link is not ready [
Bug#622833: linux-image-2.6.38-2-686: kernel panic in mac80211
Package: linux-2.6
Version: 2.6.38-3
Severity: critical
Justification: breaks the whole system
Booting panics when bringing interfaces up, including a Wi-Fi adm8211
from drivers/net/wireless. The stack trace mentions
ieee80211_rx_handlers in mac80211, net_receive_skb, do_page_fault,
bad_area_nosemaphore, no_context (from the least to the most recently
called).
I will send screenshots of the trace.
-- Package-specific info:
** Kernel log: boot messages should be attached
** Model information
not available
** Network interface configuration:
auto tp
iface tp inet static
address 192.168.3.1
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255
auto wl
iface wl inet static
address 192.168.2.172
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
dns-nameservers 192.168.2.1
wpa-ssid D3
wpa-bsssid 00:21:91:F8:36:6E
wpa-psk *
up sleep 5; /sbin/iwconfig ${IFACE}
up /sbin/ip route add 224.0.0.0/4 dev ${IFACE}
iface tun6to4 inet6 v4tunnel
address $(printf 2002:%02x%02x:%02x%02x::1 \
$(printf %s\r\n%s\r\n\r\n \
GET / HTTP/1.1 \
Host: checkip.dyndns.org \
| /bin/nc checkip.dyndns.org 80 \
| /bin/sed -ne 's/.*Address: \([.0-9]*\).*/\1/p' \
| tr '.' ' ') \
)
netmask 16
endpoint 192.88.99.1
local any
ttl 64
up /sbin/ip -6 route add 2000::/3 dev tun6to4
down /sbin/ip -6 route flush dev tun6to4
auto lo
iface lo inet loopback
** PCI devices:
00:00.0 Host bridge [0600]: ATI Technologies Inc Radeon Xpress 200 Host Bridge
[1002:5a33] (rev 01)
Subsystem: ASUSTeK Computer Inc. Device [1043:819a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort+ SERR- PERR- INTx-
Latency: 64
Region 3: Memory at e000 (64-bit, non-prefetchable) [size=512M]
00:01.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a3f]
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: c000-cfff
Memory behind bridge: c000-dfdf
Prefetchable memory behind bridge: a000-afff
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort+ SERR- PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [b0] Subsystem: ATI Technologies Inc RS480 PCI Bridge
[1002:5a3f]
00:05.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a37]
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR+ PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: d000-dfff
Memory behind bridge: dfe0-dfef
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR-
BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns,
L1 1us
ExtTag+ RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x2, ASPM L0s L1, Latency
L0 64ns, L1 1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Bug#622828: linux-image-2.6.32-5-686: kernel panic mentions libata in the stack trace
Package: linux-2.6 Version: 2.6.32-30 Severity: critical Justification: breaks the whole system Both normal and safe boot modes panicked when running the ram disk image. Worse, the upgrade DELETED the earlier kernel image and ram disk image. I managed to boot by editing the safe mode command line and adding the option init=/bin/bash. When the kernel panicks, it shows a stack trace mentioning libata. -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-30) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 12 04:01:41 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=281d76c7-ee09-4f0e-825b-425e95d75878 ro single init=/bin/bash ** Not tainted ** Kernel log: [3.331507] PM: Checking hibernation image. [3.331689] PM: Error -22 checking image file [3.331692] PM: Resume from disk failed. [3.338369] PM: Marking nosave pages: 0009f000 - 0010 [3.338378] PM: Basic memory bitmaps created [3.345712] PM: Basic memory bitmaps freed [3.372024] usb 2-1: new full speed USB device using ohci_hcd and address 2 [3.401886] kjournald starting. Commit interval 5 seconds [3.401897] EXT3-fs: mounted filesystem with ordered data mode. [3.568751] usb 2-1: New USB device found, idVendor=03f0, idProduct=0517 [3.568808] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.568857] usb 2-1: Product: hp LaserJet 1000 [3.568903] usb 2-1: Manufacturer: Hewlett-Packard [3.569118] usb 2-1: configuration #1 chosen from 1 choice [7.505287] usb-storage: device scan complete [7.506404] scsi 6:0:0:0: Direct-Access RIM BlackBerry SD0003 PQ: 0 ANSI: 4 CCS [7.507080] sd 6:0:0:0: Attached scsi generic sg2 type 0 [7.508515] sd 6:0:0:0: [sdb] Attached SCSI removable disk [ 184.561988] EXT3 FS on sda1, internal journal [ 1241.810372] 30udev[382]: starting version 167 [ 1242.505471] 30udev[405]: renamed network interface eth0 to tp [ 1243.710686] input: PC Speaker as /devices/platform/pcspkr/input/input2 [ 1244.157244] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1244.250681] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input3 [ 1244.250866] ACPI: Power Button [PWRB] [ 1244.251036] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4 [ 1244.251271] ACPI: Power Button [PWRF] [ 1244.613408] processor LNXCPU:00: registered as cooling_device0 [ 1244.614971] processor LNXCPU:01: registered as cooling_device1 [ 1244.619420] usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x03F0 pid 0x0517 [ 1244.619503] usbcore: registered new interface driver usblp [ 1244.625601] parport_pc 00:06: reported by Plug and Play ACPI [ 1244.627407] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] [ 1244.639042] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 1245.015484] ali1535_smbus :00:1e.1: ALI1535_smb region uninitialized - upgrade BIOS? [ 1245.015576] ali1535_smbus :00:1e.1: ALI1535 not detected, module not inserted. [ 1245.025103] ali15x3_smbus :00:1e.1: ALI15X3_smb region uninitialized - upgrade BIOS or use force_addr=0xaddr [ 1245.025165] ali15x3_smbus :00:1e.1: ALI15X3 not detected, module not inserted. [ 1245.089649] alim7101_wdt: Steve Hill st...@navaho.co.uk. [ 1245.089710] alim7101_wdt: ALi 1543 South-Bridge not present - WDT not set [ 1245.404977] cfg80211: Using static regulatory domain info [ 1245.405031] cfg80211: Regulatory domain: US [ 1245.405076] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 1245.405130] (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) [ 1245.405178] (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405226] (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405274] (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405322] (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405369] (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [ 1245.405922] cfg80211: Calling CRDA for country: US [ 1245.609148] adm8211 :03:11.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 1245.619583] :03:11.0 (adm8211): Channel range: 1 - 11 [ 1245.619588] :03:11.0 (adm8211): RFtype=1 BBPtype=1 Specific BBP=0 Transceiver=0 [ 1246.177701] phy0: Selected rate control algorithm 'minstrel' [ 1246.178756] phy0: hwaddr 00:04:e2:7b:70:6b, Rev 0x11 [ 1246.189113] 30udev[403]: renamed network interface wlan0 to wl [ 1246.938086] HDA Intel :00:1d.0: PCI INT C - GSI 22 (level, low) - IRQ 22 [ 1246.938155] hda_intel: position_fix set to 1 for device 1043:81b3 [ 1247.383775] input: HDA Digital PCBeep as /devices/pci:00/:00:1d.0/input/input5 [ 1252.897954] usblp0: removed [ 1323.238716] r8169: tp: link down [ 1323.238987] ADDRCONF(NETDEV_UP): tp: link is not ready [ 1332.520717] ADDRCONF(NETDEV_UP): wl: link is not ready [
Bug#622833: linux-image-2.6.38-2-686: kernel panic in mac80211
Package: linux-2.6
Version: 2.6.38-3
Severity: critical
Justification: breaks the whole system
Booting panics when bringing interfaces up, including a Wi-Fi adm8211
from drivers/net/wireless. The stack trace mentions
ieee80211_rx_handlers in mac80211, net_receive_skb, do_page_fault,
bad_area_nosemaphore, no_context (from the least to the most recently
called).
I will send screenshots of the trace.
-- Package-specific info:
** Kernel log: boot messages should be attached
** Model information
not available
** Network interface configuration:
auto tp
iface tp inet static
address 192.168.3.1
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255
auto wl
iface wl inet static
address 192.168.2.172
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
dns-nameservers 192.168.2.1
wpa-ssid D3
wpa-bsssid 00:21:91:F8:36:6E
wpa-psk *
up sleep 5; /sbin/iwconfig ${IFACE}
up /sbin/ip route add 224.0.0.0/4 dev ${IFACE}
iface tun6to4 inet6 v4tunnel
address $(printf 2002:%02x%02x:%02x%02x::1 \
$(printf %s\r\n%s\r\n\r\n \
GET / HTTP/1.1 \
Host: checkip.dyndns.org \
| /bin/nc checkip.dyndns.org 80 \
| /bin/sed -ne 's/.*Address: \([.0-9]*\).*/\1/p' \
| tr '.' ' ') \
)
netmask 16
endpoint 192.88.99.1
local any
ttl 64
up /sbin/ip -6 route add 2000::/3 dev tun6to4
down /sbin/ip -6 route flush dev tun6to4
auto lo
iface lo inet loopback
** PCI devices:
00:00.0 Host bridge [0600]: ATI Technologies Inc Radeon Xpress 200 Host Bridge
[1002:5a33] (rev 01)
Subsystem: ASUSTeK Computer Inc. Device [1043:819a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort+ SERR- PERR- INTx-
Latency: 64
Region 3: Memory at e000 (64-bit, non-prefetchable) [size=512M]
00:01.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a3f]
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: c000-cfff
Memory behind bridge: c000-dfdf
Prefetchable memory behind bridge: a000-afff
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort+ SERR- PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [b0] Subsystem: ATI Technologies Inc RS480 PCI Bridge
[1002:5a3f]
00:05.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a37]
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR+ PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: d000-dfff
Memory behind bridge: dfe0-dfef
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR-
BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns,
L1 1us
ExtTag+ RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x2, ASPM L0s L1, Latency
L0 64ns, L1 1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Bug#622828: linux-image-2.6.32-5-686: kernel panic mentions libata in the stack trace
Package: linux-2.6 Version: 2.6.32-30 Severity: critical Justification: breaks the whole system Both normal and safe boot modes panicked when running the ram disk image. Worse, the upgrade DELETED the earlier kernel image and ram disk image. I managed to boot by editing the safe mode command line and adding the option init=/bin/bash. When the kernel panicks, it shows a stack trace mentioning libata. -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-30) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 12 04:01:41 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=281d76c7-ee09-4f0e-825b-425e95d75878 ro single init=/bin/bash ** Not tainted ** Kernel log: [3.331507] PM: Checking hibernation image. [3.331689] PM: Error -22 checking image file [3.331692] PM: Resume from disk failed. [3.338369] PM: Marking nosave pages: 0009f000 - 0010 [3.338378] PM: Basic memory bitmaps created [3.345712] PM: Basic memory bitmaps freed [3.372024] usb 2-1: new full speed USB device using ohci_hcd and address 2 [3.401886] kjournald starting. Commit interval 5 seconds [3.401897] EXT3-fs: mounted filesystem with ordered data mode. [3.568751] usb 2-1: New USB device found, idVendor=03f0, idProduct=0517 [3.568808] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.568857] usb 2-1: Product: hp LaserJet 1000 [3.568903] usb 2-1: Manufacturer: Hewlett-Packard [3.569118] usb 2-1: configuration #1 chosen from 1 choice [7.505287] usb-storage: device scan complete [7.506404] scsi 6:0:0:0: Direct-Access RIM BlackBerry SD0003 PQ: 0 ANSI: 4 CCS [7.507080] sd 6:0:0:0: Attached scsi generic sg2 type 0 [7.508515] sd 6:0:0:0: [sdb] Attached SCSI removable disk [ 184.561988] EXT3 FS on sda1, internal journal [ 1241.810372] 30udev[382]: starting version 167 [ 1242.505471] 30udev[405]: renamed network interface eth0 to tp [ 1243.710686] input: PC Speaker as /devices/platform/pcspkr/input/input2 [ 1244.157244] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1244.250681] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input3 [ 1244.250866] ACPI: Power Button [PWRB] [ 1244.251036] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4 [ 1244.251271] ACPI: Power Button [PWRF] [ 1244.613408] processor LNXCPU:00: registered as cooling_device0 [ 1244.614971] processor LNXCPU:01: registered as cooling_device1 [ 1244.619420] usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x03F0 pid 0x0517 [ 1244.619503] usbcore: registered new interface driver usblp [ 1244.625601] parport_pc 00:06: reported by Plug and Play ACPI [ 1244.627407] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] [ 1244.639042] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 1245.015484] ali1535_smbus :00:1e.1: ALI1535_smb region uninitialized - upgrade BIOS? [ 1245.015576] ali1535_smbus :00:1e.1: ALI1535 not detected, module not inserted. [ 1245.025103] ali15x3_smbus :00:1e.1: ALI15X3_smb region uninitialized - upgrade BIOS or use force_addr=0xaddr [ 1245.025165] ali15x3_smbus :00:1e.1: ALI15X3 not detected, module not inserted. [ 1245.089649] alim7101_wdt: Steve Hill st...@navaho.co.uk. [ 1245.089710] alim7101_wdt: ALi 1543 South-Bridge not present - WDT not set [ 1245.404977] cfg80211: Using static regulatory domain info [ 1245.405031] cfg80211: Regulatory domain: US [ 1245.405076] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 1245.405130] (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) [ 1245.405178] (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405226] (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405274] (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405322] (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 1245.405369] (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [ 1245.405922] cfg80211: Calling CRDA for country: US [ 1245.609148] adm8211 :03:11.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 1245.619583] :03:11.0 (adm8211): Channel range: 1 - 11 [ 1245.619588] :03:11.0 (adm8211): RFtype=1 BBPtype=1 Specific BBP=0 Transceiver=0 [ 1246.177701] phy0: Selected rate control algorithm 'minstrel' [ 1246.178756] phy0: hwaddr 00:04:e2:7b:70:6b, Rev 0x11 [ 1246.189113] 30udev[403]: renamed network interface wlan0 to wl [ 1246.938086] HDA Intel :00:1d.0: PCI INT C - GSI 22 (level, low) - IRQ 22 [ 1246.938155] hda_intel: position_fix set to 1 for device 1043:81b3 [ 1247.383775] input: HDA Digital PCBeep as /devices/pci:00/:00:1d.0/input/input5 [ 1252.897954] usblp0: removed [ 1323.238716] r8169: tp: link down [ 1323.238987] ADDRCONF(NETDEV_UP): tp: link is not ready [ 1332.520717] ADDRCONF(NETDEV_UP): wl: link is not ready [
Bug#622833: linux-image-2.6.38-2-686: kernel panic in mac80211
Package: linux-2.6
Version: 2.6.38-3
Severity: critical
Justification: breaks the whole system
Booting panics when bringing interfaces up, including a Wi-Fi adm8211
from drivers/net/wireless. The stack trace mentions
ieee80211_rx_handlers in mac80211, net_receive_skb, do_page_fault,
bad_area_nosemaphore, no_context (from the least to the most recently
called).
I will send screenshots of the trace.
-- Package-specific info:
** Kernel log: boot messages should be attached
** Model information
not available
** Network interface configuration:
auto tp
iface tp inet static
address 192.168.3.1
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255
auto wl
iface wl inet static
address 192.168.2.172
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
dns-nameservers 192.168.2.1
wpa-ssid D3
wpa-bsssid 00:21:91:F8:36:6E
wpa-psk *
up sleep 5; /sbin/iwconfig ${IFACE}
up /sbin/ip route add 224.0.0.0/4 dev ${IFACE}
iface tun6to4 inet6 v4tunnel
address $(printf 2002:%02x%02x:%02x%02x::1 \
$(printf %s\r\n%s\r\n\r\n \
GET / HTTP/1.1 \
Host: checkip.dyndns.org \
| /bin/nc checkip.dyndns.org 80 \
| /bin/sed -ne 's/.*Address: \([.0-9]*\).*/\1/p' \
| tr '.' ' ') \
)
netmask 16
endpoint 192.88.99.1
local any
ttl 64
up /sbin/ip -6 route add 2000::/3 dev tun6to4
down /sbin/ip -6 route flush dev tun6to4
auto lo
iface lo inet loopback
** PCI devices:
00:00.0 Host bridge [0600]: ATI Technologies Inc Radeon Xpress 200 Host Bridge
[1002:5a33] (rev 01)
Subsystem: ASUSTeK Computer Inc. Device [1043:819a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort+ SERR- PERR- INTx-
Latency: 64
Region 3: Memory at e000 (64-bit, non-prefetchable) [size=512M]
00:01.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a3f]
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: c000-cfff
Memory behind bridge: c000-dfdf
Prefetchable memory behind bridge: a000-afff
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort+ SERR- PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [b0] Subsystem: ATI Technologies Inc RS480 PCI Bridge
[1002:5a3f]
00:05.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a37]
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR+ PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: d000-dfff
Memory behind bridge: dfe0-dfef
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR-
BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns,
L1 1us
ExtTag+ RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x2, ASPM L0s L1, Latency
L0 64ns, L1 1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
[bug #28983] forcing a target matching a pattern rule shadows the rule's actions
Follow-up Comment #4, bug #28983 (project make): The GNU make manual both supports and defeats Matt's statement. A phony target is one that is not really the name of a file. [..] Once this is done, `make clean' will run the commands regardless of whether there is a file named clean. It would be a nuisance for the builds of pre-requisites of .PHONY to depend on existence of the files by the same name. Introducing an intermediate dependency can only reduce but not completely eliminate the possibility of a name clash. ___ Reply to this item at: http://savannah.gnu.org/bugs/?28983 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #28983] forcing a target matching a pattern rule shadows the rule's actions
Follow-up Comment #6, bug #28983 (project make): The following tests show that .PHONY's pre-requisites are normally rebuilt regardless of existence of a file with the same name. This works, $ cat test-force.mak default: file.o .PHONY: file.o file.o: echo Building $...@... $@ $ make -f test-force.mak echo Building file.o... file.o $ ls -al file.o -rw-r--r-- 1 ilatypov Domain Users 19 May 7 19:58 file.o $ rm file.o $ make -f test-force.mak echo Building file.o... file.o $ ls -al file.o -rw-r--r-- 1 ilatypov Domain Users 19 May 7 19:58 file.o $ make -f test-force.mak echo Building file.o... file.o +verbatim- And this works, $ cat test-force2.mak default: file.o .PHONY: file.o file.c: echo Auto-generating $...@... $@ file.o: file.c @echo Building $@ from $^... cat $^ $@ $ rm file.c file.o $ make -f test-force2.mak echo Auto-generating file.c... file.c Building file.o from file.c... cat file.c file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o $ rm file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o +verbatim- But this does not, $ cat test-force3.mak default: file.o .PHONY: file.o file.c: echo Auto-generating $...@... $@ %.o: %.c @echo Building $@ from $^... cat $^ $@ $ rm -f file.c file.o $ make -f test-force3.mak make: Nothing to be done for `default'. +verbatim- This allows me to think that my expectation in the original bug report was valid. And a pattern rule should not be affected by the phoniness of a target. ___ Reply to this item at: http://savannah.gnu.org/bugs/?28983 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #28983] forcing a target matching a pattern rule shadows the rule's actions
Follow-up Comment #7, bug #28983 (project make): The following tests show that .PHONY's pre-requisites are normally rebuilt regardless of existence of a file with the same name. This works, $ cat test-force.mak default: file.o .PHONY: file.o file.o: echo Building $...@... $@ $ make -f test-force.mak echo Building file.o... file.o $ ls -al file.o -rw-r--r-- 1 ilatypov Domain Users 19 May 7 19:58 file.o $ rm file.o $ make -f test-force.mak echo Building file.o... file.o $ ls -al file.o -rw-r--r-- 1 ilatypov Domain Users 19 May 7 19:58 file.o $ make -f test-force.mak echo Building file.o... file.o And this works, $ cat test-force2.mak default: file.o .PHONY: file.o file.c: echo Auto-generating $...@... $@ file.o: file.c @echo Building $@ from $^... cat $^ $@ $ rm file.c file.o $ make -f test-force2.mak echo Auto-generating file.c... file.c Building file.o from file.c... cat file.c file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o $ rm file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o But this does not, $ cat test-force3.mak default: file.o .PHONY: file.o file.c: echo Auto-generating $...@... $@ %.o: %.c @echo Building $@ from $^... cat $^ $@ $ rm -f file.c file.o $ make -f test-force3.mak make: Nothing to be done for `default'. This allows me to think that my expectation in the original bug report was valid. And a pattern rule should not be affected by the phoniness of a target. ___ Reply to this item at: http://savannah.gnu.org/bugs/?28983 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Bug#579340: [CRASH] Uncaught exception AttributeError in Frontend/Gtk/ui.py:616
Package: update-manager-gnome
Version: 0.200.3-1
Severity: grave
File: /usr/share/pyshared/UpdateManager/Frontend/Gtk/ui.py
Tags: sid
Justification: renders package unusable
Update Manager crashed on its start.
*** /tmp/update-manager-bugm_Su6p
The information below has been automatically generated.
Please do not remove this from your bug report.
- Exception Type: type 'exceptions.AttributeError'
- Exception Value: AttributeError('GtkUI' object has no attribute
'treeview_update',)
- Exception Origin: _MainThread(MainThread, started)
- Exception Traceback:
File /usr/bin/update-manager, line 38, in module
app.main()
File /usr/lib/pymodules/python2.5/UpdateManager/Application.py, line 421,
in main
self._frontend.init_frontend()
File /usr/lib/pymodules/python2.5/UpdateManager/Frontend/Gtk/__init__.py,
line 70, in init_frontend
self._ui = GtkUI(self)
File /usr/lib/pymodules/python2.5/UpdateManager/Frontend/Gtk/ui.py, line
616, in __init__
self.update_list = UpdateListControl(self, self.treeview_update)
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages update-manager-gnome depends on:
ii gconf22.28.1-3 GNOME configuration database syste
ii gksu 2.0.2-2+b1 graphical frontend to su
ii python2.5.4-9An interactive high-level object-o
ii python-dbus 0.83.1-1 simple interprocess messaging syst
ii python-gconf 2.28.1-1 Python bindings for the GConf conf
ii python-gobject2.21.1-1 Python bindings for the GObject li
ii python-gtk2 2.17.0-2 Python bindings for the GTK+ widge
ii python-support1.0.8 automated rebuilding support for P
ii python-vte1:0.24.0-2 Python bindings for the VTE widget
ii update-manager-core 0.200.3-1 APT update manager core functional
update-manager-gnome recommends no packages.
Versions of packages update-manager-gnome suggests:
ii software-properties-gtk 0.60.debian-1.1 manage the repositories that you i
ii update-notifier 0.99.3debian3 Daemon which notifies about packag
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579340: [CRASH] Uncaught exception AttributeError in Frontend/Gtk/ui.py:616
Package: update-manager-gnome
Version: 0.200.3-1
Severity: grave
File: /usr/share/pyshared/UpdateManager/Frontend/Gtk/ui.py
Tags: sid
Justification: renders package unusable
Update Manager crashed on its start.
*** /tmp/update-manager-bugm_Su6p
The information below has been automatically generated.
Please do not remove this from your bug report.
- Exception Type: type 'exceptions.AttributeError'
- Exception Value: AttributeError('GtkUI' object has no attribute
'treeview_update',)
- Exception Origin: _MainThread(MainThread, started)
- Exception Traceback:
File /usr/bin/update-manager, line 38, in module
app.main()
File /usr/lib/pymodules/python2.5/UpdateManager/Application.py, line 421,
in main
self._frontend.init_frontend()
File /usr/lib/pymodules/python2.5/UpdateManager/Frontend/Gtk/__init__.py,
line 70, in init_frontend
self._ui = GtkUI(self)
File /usr/lib/pymodules/python2.5/UpdateManager/Frontend/Gtk/ui.py, line
616, in __init__
self.update_list = UpdateListControl(self, self.treeview_update)
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages update-manager-gnome depends on:
ii gconf22.28.1-3 GNOME configuration database syste
ii gksu 2.0.2-2+b1 graphical frontend to su
ii python2.5.4-9An interactive high-level object-o
ii python-dbus 0.83.1-1 simple interprocess messaging syst
ii python-gconf 2.28.1-1 Python bindings for the GConf conf
ii python-gobject2.21.1-1 Python bindings for the GObject li
ii python-gtk2 2.17.0-2 Python bindings for the GTK+ widge
ii python-support1.0.8 automated rebuilding support for P
ii python-vte1:0.24.0-2 Python bindings for the VTE widget
ii update-manager-core 0.200.3-1 APT update manager core functional
update-manager-gnome recommends no packages.
Versions of packages update-manager-gnome suggests:
ii software-properties-gtk 0.60.debian-1.1 manage the repositories that you i
ii update-notifier 0.99.3debian3 Daemon which notifies about packag
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578296: git-core: ValueError: too many values to unpack
Thanks for the proposed patch. Anyhow, the right solution is to simply ignore that extra value in the module that parses them [..] conffiles = conffiles + [tuple(line.split()[:2])] Nice. Thanks, Sandro. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578596: Fails to install, variable used before assignment
Package: python2.5-minimal Version: 2.5.5-5 Severity: normal I wonder if this can be fixed with the following change, --- /usr/lib/python2.5/py_compile.py.orig 2010-04-21 06:00:38.0 -0400 +++ /usr/lib/python2.5/py_compile.py2010-04-21 05:46:52.0 -0400 @@ -153,6 +153,7 @@ files is taken from standard input. +rv = 0 if args is None: args = sys.argv[1:] if args == ['-']: -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-2-686 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python2.5-minimal depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages python2.5-minimal recommends: ii python2.5 2.5.5-5An interactive high-level object-o Versions of packages python2.5-minimal suggests: ii binfmt-support1.2.18 Support for extra binary formats -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578296: git-core: ValueError: too many values to unpack
Package: reportbug
Version: 4.12
Severity: normal
This appears to be a result of an extra word obsolete in addition to
filename and md5sum fields of a conffiles record. Reproduced when
reporting on python2.5-minimal.
=
il...@ei:~$ dpkg --status python2.5-minimal
Package: python2.5-minimal
Status: install ok installed
Priority: optional
Section: python
Installed-Size: 4316
Maintainer: Matthias Klose d...@debian.org
Architecture: i386
Source: python2.5
Version: 2.5.5-5
Replaces: python2.5 ( 2.5.2-1)
Depends: libc6 (= 2.3.6-6~), zlib1g (= 1:1.2.0)
Recommends: python2.5
Suggests: binfmt-support
Conflicts: binfmt-support ( 1.1.2)
Conffiles:
/etc/python2.5/sitecustomize.py d6b276695157bde06a56ba1b2bc53670
/etc/python2.5/site.py f10d07f5be789964fff663e2dfe560f9 obsolete
Description: A minimal subset of the Python language (version 2.5)
This package contains the interpreter and some essential modules. It can
be used in the boot process for some basic tasks.
See /usr/share/doc/python2.5-minimal/README.Debian for a list of the modules
contained in this package.
Homepage: http://python.org/
Python-Runtime: python2.5
Python-Version: 2.5
=
I wonder if ignoring any extra information in conffiles records addresses the
root cause properly. Here is the change I am suggesting.
=
--- /usr/share/pyshared/reportbug/utils.py.orig 2010-04-21 05:58:15.0
-0400
+++ /usr/share/pyshared/reportbug/utils.py 2010-04-21 05:56:05.0 -0400
@@ -641,7 +641,9 @@
def get_changed_config_files(conffiles, nocompress=False):
confinfo = {}
changed = []
-for (filename, md5sum) in conffiles:
+for cf in conffiles:
+filename = cf[ 0 ]
+md5sum = cf[ 1 ]
try:
fp = file(filename)
except IOError, msg:
=
-- Package-specific info:
** Environment settings:
EDITOR=vi
INTERFACE=text
** /home/ilgiz/.reportbugrc:
reportbug_version 3.21.2
mode standard
ui text
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages reportbug depends on:
ii apt 0.7.25.3 Advanced front-end for dpkg
ii python2.5.4-9An interactive high-level object-o
ii python-reportbug 4.12 Python modules for interacting wit
reportbug recommends no packages.
Versions of packages reportbug suggests:
ii debconf-utils1.5.32 debconf utilities
pn debsums none (no description available)
pn dlocate none (no description available)
ii emacs23-bin-common 23.1+1-6The GNU Emacs editor's shared, arc
ii exim44.71-4 metapackage to ease Exim MTA (v4)
ii exim4-daemon-heavy [ 4.71-4 Exim MTA (v4) daemon with extended
ii file 5.04-2 Determines file type using magic
ii gnupg1.4.10-3GNU privacy guard - a free PGP rep
ii python-gtk2 2.17.0-2Python bindings for the GTK+ widge
pn python-gtkspell none (no description available)
pn python-urwid none (no description available)
ii python-vte 1:0.24.0-2 Python bindings for the VTE widget
ii xdg-utils1.0.2+cvs20100307-1 desktop integration utilities from
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[Reportbug-maint] Bug#578296: git-core: ValueError: too many values to unpack
Package: reportbug
Version: 4.12
Severity: normal
This appears to be a result of an extra word obsolete in addition to
filename and md5sum fields of a conffiles record. Reproduced when
reporting on python2.5-minimal.
=
il...@ei:~$ dpkg --status python2.5-minimal
Package: python2.5-minimal
Status: install ok installed
Priority: optional
Section: python
Installed-Size: 4316
Maintainer: Matthias Klose d...@debian.org
Architecture: i386
Source: python2.5
Version: 2.5.5-5
Replaces: python2.5 ( 2.5.2-1)
Depends: libc6 (= 2.3.6-6~), zlib1g (= 1:1.2.0)
Recommends: python2.5
Suggests: binfmt-support
Conflicts: binfmt-support ( 1.1.2)
Conffiles:
/etc/python2.5/sitecustomize.py d6b276695157bde06a56ba1b2bc53670
/etc/python2.5/site.py f10d07f5be789964fff663e2dfe560f9 obsolete
Description: A minimal subset of the Python language (version 2.5)
This package contains the interpreter and some essential modules. It can
be used in the boot process for some basic tasks.
See /usr/share/doc/python2.5-minimal/README.Debian for a list of the modules
contained in this package.
Homepage: http://python.org/
Python-Runtime: python2.5
Python-Version: 2.5
=
I wonder if ignoring any extra information in conffiles records addresses the
root cause properly. Here is the change I am suggesting.
=
--- /usr/share/pyshared/reportbug/utils.py.orig 2010-04-21 05:58:15.0
-0400
+++ /usr/share/pyshared/reportbug/utils.py 2010-04-21 05:56:05.0 -0400
@@ -641,7 +641,9 @@
def get_changed_config_files(conffiles, nocompress=False):
confinfo = {}
changed = []
-for (filename, md5sum) in conffiles:
+for cf in conffiles:
+filename = cf[ 0 ]
+md5sum = cf[ 1 ]
try:
fp = file(filename)
except IOError, msg:
=
-- Package-specific info:
** Environment settings:
EDITOR=vi
INTERFACE=text
** /home/ilgiz/.reportbugrc:
reportbug_version 3.21.2
mode standard
ui text
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages reportbug depends on:
ii apt 0.7.25.3 Advanced front-end for dpkg
ii python2.5.4-9An interactive high-level object-o
ii python-reportbug 4.12 Python modules for interacting wit
reportbug recommends no packages.
Versions of packages reportbug suggests:
ii debconf-utils1.5.32 debconf utilities
pn debsums none (no description available)
pn dlocate none (no description available)
ii emacs23-bin-common 23.1+1-6The GNU Emacs editor's shared, arc
ii exim44.71-4 metapackage to ease Exim MTA (v4)
ii exim4-daemon-heavy [ 4.71-4 Exim MTA (v4) daemon with extended
ii file 5.04-2 Determines file type using magic
ii gnupg1.4.10-3GNU privacy guard - a free PGP rep
ii python-gtk2 2.17.0-2Python bindings for the GTK+ widge
pn python-gtkspell none (no description available)
pn python-urwid none (no description available)
ii python-vte 1:0.24.0-2 Python bindings for the VTE widget
ii xdg-utils1.0.2+cvs20100307-1 desktop integration utilities from
-- no debconf information
___
Reportbug-maint mailing list
Reportbug-maint@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/reportbug-maint
Bug#578596: Fails to install, variable used before assignment
Package: python2.5-minimal Version: 2.5.5-5 Severity: normal I wonder if this can be fixed with the following change, --- /usr/lib/python2.5/py_compile.py.orig 2010-04-21 06:00:38.0 -0400 +++ /usr/lib/python2.5/py_compile.py2010-04-21 05:46:52.0 -0400 @@ -153,6 +153,7 @@ files is taken from standard input. +rv = 0 if args is None: args = sys.argv[1:] if args == ['-']: -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-2-686 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python2.5-minimal depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages python2.5-minimal recommends: ii python2.5 2.5.5-5An interactive high-level object-o Versions of packages python2.5-minimal suggests: ii binfmt-support1.2.18 Support for extra binary formats -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[jira] Commented: (NUTCH-427) protocol-smb: plugin protocol implementing the CIFS/SMB protocol. This protocol allows Nutch to crawl Microsoft Windows Shares remotely using the CIFS/SMB protocol implme
[
https://issues.apache.org/jira/browse/NUTCH-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12859116#action_12859116
]
Ilguiz Latypov commented on NUTCH-427:
--
I hesitate adding the .zip file because (a) it hides the intention of the
change and (b) other developers who might have already modified their copies
would have difficulty merging my change.
I believe the GNU patch tool will apply my suggested change automatically,
provided that one resides in the right working directory and, possibly, applies
the -pX option where X is the number of upper level directory names to ignore
in the patch.
protocol-smb: plugin protocol implementing the CIFS/SMB protocol. This
protocol allows Nutch to crawl Microsoft Windows Shares remotely using the
CIFS/SMB protocol implmentation.
--
Key: NUTCH-427
URL: https://issues.apache.org/jira/browse/NUTCH-427
Project: Nutch
Issue Type: New Feature
Components: fetcher
Affects Versions: 0.8.1, 0.9.0, 1.0.0
Environment: JAVA - OS independent
Reporter: Armel Nene
Priority: Minor
Attachments: protocol-smb-diff.txt, protocol-smb.zip,
protocol-smb.zip, protocol-smb.zip
Title:protocol-smb - Nutch protocol plugin for crawling Microsoft Windows
shares
Author: Armel T. Nene
Update: Vadim Bauer
Email:armel.nene NOSPAM-AT-NOSPAM idna-solutions.com, V a d i m B a u e r
AT g m x . d e
A. Introduction
The protocol-smb plugins allows you to crawl Microsoft Windows shares. It
implements
the CIFS/SMB protocol which is commonly used on Microsoft OS. The plugin
replicate the
behaviour of the protocol-file over CIFS/SMB protocol. This plugin uses
the JCifs library and also
support all the properties from the JCifs library.
You can find more information on the following site:
http://jcifs.samba.org/
The smb protocol syntax for crawling is as follow: smb://x (i.e.
smb://server/share).
B. Installation
1) Binaries only: The protocol-smb files can be found in the ../plugins
directory.
Copy the protocol-smb to
NUTCHHOME/build/plugins directory.
Put the smb.properties file in the NUTCHHOME/conf
directory.
Configure the properties in smb.properties file
Enable the plugin by updating nutch-site.xml file
found in NUTCHHOME/conf directory
e.g. property
nameplugin.includes/name
valueprotocol-smb| other
plugins.../value
description
/description
/property
2) Source code:The protocol-smb sources can be found in the ../src
directory.
Always refer to the Nutch wiki for detailed
instructions on building Nutch. In short:
Copy the 'protocol-smb' folder to NUTCHHOME/src/plugin
Update the build.xml in NUTCHHOME/src/plugin to
include plugin
Update the NUTCHHOME/default.properties file to
include plugin
run ant to build
Copy the 'smb.properties' file to NUTCHHOME/conf, and
configure the properties
Enable the plugin by updating the nutch-site.xml file
C: Known Issues
1) URLMalformedException: unkown protocol: smb
The SMB URL protocol handler is not being successfully installed.
In short, the jCIFS jar must be loaded by the System class loader.
Workaround: a) a short term solutions will be to installed the JCIFS
jar
library found in protocol-smb folder in
JDKHOME/jre/lib/ext and (or) JREHOME/lib/ext
b) After completing step a), if the exeception is still
thrown
set the System properties by passing the following
arguments
to the JVM:
-Djava.protocol.handler.pkgs=jcifs
c) You can set the property also in your Code for
example if
you start Crawling with org.apache.nutch.crawl.Crawl
Add the following two lines. This will be the Same
like in b)
public static void main(String args[]) throws
Exception {
System.setProperty(java.protocol.handler.pkgs, jcifs);
new
[jira] Updated: (NUTCH-427) protocol-smb: plugin protocol implementing the CIFS/SMB protocol. This protocol allows Nutch to crawl Microsoft Windows Shares remotely using the CIFS/SMB protocol implment
[
https://issues.apache.org/jira/browse/NUTCH-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilguiz Latypov updated NUTCH-427:
-
Attachment: (was: protocol-smb.zip)
protocol-smb: plugin protocol implementing the CIFS/SMB protocol. This
protocol allows Nutch to crawl Microsoft Windows Shares remotely using the
CIFS/SMB protocol implmentation.
--
Key: NUTCH-427
URL: https://issues.apache.org/jira/browse/NUTCH-427
Project: Nutch
Issue Type: New Feature
Components: fetcher
Affects Versions: 0.8.1, 0.9.0, 1.0.0
Environment: JAVA - OS independent
Reporter: Armel Nene
Priority: Minor
Attachments: protocol-smb-diff.txt, protocol-smb.zip, protocol-smb.zip
Title:protocol-smb - Nutch protocol plugin for crawling Microsoft Windows
shares
Author: Armel T. Nene
Update: Vadim Bauer
Email:armel.nene NOSPAM-AT-NOSPAM idna-solutions.com, V a d i m B a u e r
AT g m x . d e
A. Introduction
The protocol-smb plugins allows you to crawl Microsoft Windows shares. It
implements
the CIFS/SMB protocol which is commonly used on Microsoft OS. The plugin
replicate the
behaviour of the protocol-file over CIFS/SMB protocol. This plugin uses
the JCifs library and also
support all the properties from the JCifs library.
You can find more information on the following site:
http://jcifs.samba.org/
The smb protocol syntax for crawling is as follow: smb://x (i.e.
smb://server/share).
B. Installation
1) Binaries only: The protocol-smb files can be found in the ../plugins
directory.
Copy the protocol-smb to
NUTCHHOME/build/plugins directory.
Put the smb.properties file in the NUTCHHOME/conf
directory.
Configure the properties in smb.properties file
Enable the plugin by updating nutch-site.xml file
found in NUTCHHOME/conf directory
e.g. property
nameplugin.includes/name
valueprotocol-smb| other
plugins.../value
description
/description
/property
2) Source code:The protocol-smb sources can be found in the ../src
directory.
Always refer to the Nutch wiki for detailed
instructions on building Nutch. In short:
Copy the 'protocol-smb' folder to NUTCHHOME/src/plugin
Update the build.xml in NUTCHHOME/src/plugin to
include plugin
Update the NUTCHHOME/default.properties file to
include plugin
run ant to build
Copy the 'smb.properties' file to NUTCHHOME/conf, and
configure the properties
Enable the plugin by updating the nutch-site.xml file
C: Known Issues
1) URLMalformedException: unkown protocol: smb
The SMB URL protocol handler is not being successfully installed.
In short, the jCIFS jar must be loaded by the System class loader.
Workaround: a) a short term solutions will be to installed the JCIFS
jar
library found in protocol-smb folder in
JDKHOME/jre/lib/ext and (or) JREHOME/lib/ext
b) After completing step a), if the exeception is still
thrown
set the System properties by passing the following
arguments
to the JVM:
-Djava.protocol.handler.pkgs=jcifs
c) You can set the property also in your Code for
example if
you start Crawling with org.apache.nutch.crawl.Crawl
Add the following two lines. This will be the Same
like in b)
public static void main(String args[]) throws
Exception {
System.setProperty(java.protocol.handler.pkgs, jcifs);
new
java.util.PropertyPermission(java.protocol.handler.pkgs,read, write)
//and so on
Also you can visit the FAQ page:
http://jcifs.samba.org/src/docs/faq.html
2) FATAL smb.SMB - Could not read content of protocol: smb://xx
This problem usually occurs if the following properties are not set
correctly in
the smb.properties file:
- username
- password
- domain
Also refer to the following resources
[jira] Updated: (NUTCH-427) protocol-smb: plugin protocol implementing the CIFS/SMB protocol. This protocol allows Nutch to crawl Microsoft Windows Shares remotely using the CIFS/SMB protocol implment
[
https://issues.apache.org/jira/browse/NUTCH-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilguiz Latypov updated NUTCH-427:
-
Attachment: protocol-smb-dist.zip
Applied my diff to simplify importing into the Subversion tree. The build
directory should not be imported, and the src/plugin/build.xml file should only
add the new protocol-smb deploy and clean targets.
The previous author did not grant the license to ASF.
protocol-smb: plugin protocol implementing the CIFS/SMB protocol. This
protocol allows Nutch to crawl Microsoft Windows Shares remotely using the
CIFS/SMB protocol implmentation.
--
Key: NUTCH-427
URL: https://issues.apache.org/jira/browse/NUTCH-427
Project: Nutch
Issue Type: New Feature
Components: fetcher
Affects Versions: 0.8.1, 0.9.0, 1.0.0
Environment: JAVA - OS independent
Reporter: Armel Nene
Priority: Minor
Attachments: protocol-smb-diff.txt, protocol-smb-dist.zip,
protocol-smb.zip, protocol-smb.zip
Title:protocol-smb - Nutch protocol plugin for crawling Microsoft Windows
shares
Author: Armel T. Nene
Update: Vadim Bauer
Email:armel.nene NOSPAM-AT-NOSPAM idna-solutions.com, V a d i m B a u e r
AT g m x . d e
A. Introduction
The protocol-smb plugins allows you to crawl Microsoft Windows shares. It
implements
the CIFS/SMB protocol which is commonly used on Microsoft OS. The plugin
replicate the
behaviour of the protocol-file over CIFS/SMB protocol. This plugin uses
the JCifs library and also
support all the properties from the JCifs library.
You can find more information on the following site:
http://jcifs.samba.org/
The smb protocol syntax for crawling is as follow: smb://x (i.e.
smb://server/share).
B. Installation
1) Binaries only: The protocol-smb files can be found in the ../plugins
directory.
Copy the protocol-smb to
NUTCHHOME/build/plugins directory.
Put the smb.properties file in the NUTCHHOME/conf
directory.
Configure the properties in smb.properties file
Enable the plugin by updating nutch-site.xml file
found in NUTCHHOME/conf directory
e.g. property
nameplugin.includes/name
valueprotocol-smb| other
plugins.../value
description
/description
/property
2) Source code:The protocol-smb sources can be found in the ../src
directory.
Always refer to the Nutch wiki for detailed
instructions on building Nutch. In short:
Copy the 'protocol-smb' folder to NUTCHHOME/src/plugin
Update the build.xml in NUTCHHOME/src/plugin to
include plugin
Update the NUTCHHOME/default.properties file to
include plugin
run ant to build
Copy the 'smb.properties' file to NUTCHHOME/conf, and
configure the properties
Enable the plugin by updating the nutch-site.xml file
C: Known Issues
1) URLMalformedException: unkown protocol: smb
The SMB URL protocol handler is not being successfully installed.
In short, the jCIFS jar must be loaded by the System class loader.
Workaround: a) a short term solutions will be to installed the JCIFS
jar
library found in protocol-smb folder in
JDKHOME/jre/lib/ext and (or) JREHOME/lib/ext
b) After completing step a), if the exeception is still
thrown
set the System properties by passing the following
arguments
to the JVM:
-Djava.protocol.handler.pkgs=jcifs
c) You can set the property also in your Code for
example if
you start Crawling with org.apache.nutch.crawl.Crawl
Add the following two lines. This will be the Same
like in b)
public static void main(String args[]) throws
Exception {
System.setProperty(java.protocol.handler.pkgs, jcifs);
new
java.util.PropertyPermission(java.protocol.handler.pkgs,read, write)
//and so on
Also you can visit the FAQ page:
http://jcifs.samba.org/src/docs/faq.html
2) FATAL
[bug #27983] Windows text mode mis-interpreted
Follow-up Comment #9, bug #27983 (project findutils): app | d2u | xargs That is a one-size-fits-all solution - it works no matter the windows app on the left and no matter the consumer on the right. This means that the developers should be aware about the newline subtlety that may be exposed by the use of Windows native applications and the Cygwin's text mode mounts. Some developers may test their changes on binary only mounts forgetting about other users who are not even aware about the kind of the mount they have. to make it easier to change an existing stream to binary-only I do not understand your point. Earlier you argued that using the 'b' option in the file open mode makes no sense on POSIX, and this is confirmed by the Open Group specs. Now you are saying that since the use of that option should be harmless on POSIX-compliant systems, we could use it so that on some specific systems this option would make a difference. But this hides the fact that Cygwin cannot be POSIX-compliant when processing arbitrary input streams or generating output streams. This is because Cygwin should take the notion of native newlines into account. As for the suggested change to either the use of freopen() or to the xfreopen() wrapper with regards to preserving the possible append mode, I agree that all uses of freopen() with w may need reviewing. I am afraid that just modifying freopen()'s implementation itself to preserve the append mode would be too drastic as this could change the existing behavior where the append mode was not supposed to be preserved. (In case of xargs, only the mode of the input stream needs to be changed, so preserving the append mode does not seem to be an issue to me). ___ Reply to this item at: http://savannah.gnu.org/bugs/?27983 ___ Message sent via/by Savannah http://savannah.gnu.org/
[bug #27983] Windows text mode mis-interpreted
Follow-up Comment #10, bug #27983 (project findutils): Cygwin cannot be POSIX-compliant I meant Cygwin applications cannot rely on POSIX compliance of the system features they consume. ___ Reply to this item at: http://savannah.gnu.org/bugs/?27983 ___ Message sent via/by Savannah http://savannah.gnu.org/
[bug #27983] Windows text mode mis-interpreted
Follow-up Comment #5, bug #27983 (project findutils):
Then you use cat, which preserves binary mode, through a pipe which also
preserves binary mode.
But this is a valid sequence of commands, and Cygwin should preserve the
behavior of this sequence regardless of the input's low-level line endings, as
long as the latter are in accord with the text mode detection rules. Pipes
are the corner case and this is why I appeal to force explicit input
conversion in Cygwin's xargs.
The attached patch made the CRs disappear on reading the pipe.
I also realized that the t and b options in the fopen() mode argument are
supposed to be irrelevant in the POSIX world.
Here are the outputs of the improved test script.
Before the patch:
$ PATH=/usr/src/findutils-4.5.5-1/build/xargs:${PATH} ./text-mode.sh
umount: /textmode: Invalid argument
mount: warning - /textmode does not exist.
CR found in /textmode/file1.txt.
*** Unexpectedly, CR found in /textmode/file2.txt.
CR found in /textmode/file3.txt.
*** Unexpectedly, CR not found in /textmode/file4.txt.
CR not found in /textmode/file5.txt.
CR not found in /textmode/file6.txt.
After the patch:
$ PATH=/usr/src/findutils-4.5.5-1/build/xargs:${PATH} ./text-mode.sh
umount: /textmode: Invalid argument
mount: warning - /textmode does not exist.
CR found in /textmode/file1.txt.
CR not found in /textmode/file2.txt.
CR found in /textmode/file3.txt.
CR found in /textmode/file4.txt.
CR not found in /textmode/file5.txt.
CR not found in /textmode/file6.txt.
(file #20165, file #20166)
___
Additional Item Attachment:
File name: xargs-4.5.5-1-explicit-text-or-binary-mode.txt Size:0 KB
File name: text-mode.sh Size:5 KB
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27983
___
Message sent via/by Savannah
http://savannah.gnu.org/
[bug #27983] Windows text mode mis-interpreted
Follow-up Comment #3, bug #27983 (project findutils):
Is the expectation in the test script valid?
mount -t $(cygpath -w ${dir}) /textmode
[..]
tf1=/textmode/file1.txt
tf2=/textmode/file2.txt
[..]
echo foo ${tf1}
echo bar ${tf1}
[..]
cat ${tf1} | xargs -i echo -n =={}== ${tf2}
[..]
find_crs ${tf2} # CR found (Savannah bug 27983 in xargs 4.4.0)
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27983
___
Message sent via/by Savannah
http://savannah.gnu.org/
Re: Ctrl-D often does not successfully exit rxvt and close it down
Anybody else? Same here. I am even ruling out any interference with programs I launch from the terminal. Last time I noticed, even running a couple of Perforce commands made it impossible to shut the terminal on exit. Also, during long ant builds I notice that the build would pause. My pressing Enter 2-3 times would cause the build continue. The pause may occur 2-3 times per build. -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
update on tr feasibility in text mode docs
The current documentation on Cygwin text mode heuristic relies on a bug in a GNU tool. That bug was fixed. http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/doc/textbinary.sgml?rev=1.11content-type=text/x-cvsweb-markupcvsroot=src The script/para screen ![CDATA[ #!/bin/sh # Remove \r from the file given as argument tr -d '\r' $1 $1.nocr ]] /screen para will not work on a text mounted systems because the \r will be reintroduced on writing.I believe GNU tr switched to always-binary output on January 1, 1999, according to its change log, http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=87f9e231c340b939bf691842df8fb30e88402acd The Cygwin example should probably be more explicit by offering C code with the fopen() w mode and a counter-example with the wb mode. I tested tr's binary output in a text mount using the attached script, https://savannah.gnu.org/bugs/?27983 The script showed that cygport's build of xargs and the pristine biuld of GNU gzip failed to use the explicit binary mode where they should. -- text-mode.sh Description: Bourne shell script -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: allow executing a path in backslash notation
I checked this situation in cmd.exe, and it is not capable of using paths relativ to %Path%. In other words, if %Path% contains a path c:\foo and you have two files C:\foo\baz.exe and C:\foo\bar\baz.exe, then calling baz works, but calling bar\baz fails. I only meant resolving relative commands against the current directory. That is, regardless of %PATH%, bar\baz is allowed to resolve if the current directory is c:\foo. The absolute paths are already resolved. My patch allows relative and absolute commands in backslash notation, as the test case shows. So, yes, maybe we should care for this situation but it's not something to worry about a lot. I'll look into it again at some point after 1.7.2 has been released. Thanks. -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7.1: cvs version built in is unstable
I check out a module of my repository (located on a remote machine) and a handful of files do not get downloaded due to the no such file error described below. Try cvs up -d or delete everything and cvs co anew. I could not check out the new directory with a simple cvs up myself. -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: allow executing a path in backslash notation
This has been changed deliberately, otherwise
the execp functions have a potential security problem. If you omit the
NNF flag, the function returns the original path unchanged, instead of
NULL.
I see that my conjecture about the root cause of the observed inconsistency was
incorrect. But my conjecture was only secondary to the patch. The conjecture
was about spawnvpe() succeeding where execvp() failed. Your answer means that
spawnvpe() should also call find_exec() with the extra 2 parameters, PATH=
and FE_NNF.
Is my primary concern still valid? I.e., should execvp..()/spawnvp..() succeed
in executing backslash notation of relative and absolute paths? If these
inputs should be allowed, did my patch address the issue correctly?
I agree that a basename-only path should not resolve against current directory
according to the execvp..() specs. I believe the relative and absolute paths
are allowed to resolve.
-- Index: spawn.cc
===
RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v
retrieving revision 1.288
diff -u -r1.288 spawn.cc
--- spawn.cc25 Jan 2010 11:21:56 - 1.288
+++ spawn.cc9 Mar 2010 00:20:54 -
@@ -112,15 +112,16 @@
char *tmp = tp.c_get ();
const char *posix = (opt FE_NATIVE) ? NULL : name;
bool has_slash = strchr (name, '/');
+ bool has_backslash = strchr (name, '\\');
int err;
/* Check to see if file can be opened as is first.
Win32 systems always check . first, but PATH may not be set up to
do this. */
- if ((has_slash || opt FE_CWD)
+ if ((has_slash || has_backslash || opt FE_CWD)
(suffix = perhaps_suffix (name, buf, err, opt)) != NULL)
{
- if (posix !has_slash)
+ if (posix !has_slash !has_backslash)
{
tmp[0] = '.';
tmp[1] = '/';
@@ -147,7 +148,7 @@
path = s;
posix_path = mywinenv - 1;
}
- else if (has_slash || strchr (name, '\\') || isdrive (name)
+ else if (has_slash || has_backslash || isdrive (name)
|| !(winpath = getwinenv (mywinenv))
|| !(path = winpath-get_native ()) || *path == '\0')
/* Return the error condition if this is an absolute path or if there
#include process.h// for spawnvpe() (not specified by The Open Group)
#include unistd.h // for execvp()
#include stdio.h // for printf()
#include errno.h // for errno
#include string.h // for strdup(), strerror()
#include stdlib.h // for getenv()
int
main (int argc, const char *argv[])
{
const char const *args[3];
char *mutable_args[3];
// See http://c-faq.com/ansi/constmismatch.html explaining that a promise
// of constness of values pointed to by pointer elements requires constness
// of pointers as well. In other words, a const char** parameter cannot
// accept a char ** argument.
const char *envp[2];
const char *pathvalue = NULL;
char *pathenv = NULL;
int ec;
if ( argc 2 ) {
return 2;
}
args[ 0 ] = argv[1];
args[ 1 ] = abc;
args[ 2 ] = NULL;
mutable_args[ 0 ] = strdup( args[ 0 ] );
mutable_args[ 1 ] = strdup( args[ 1 ] );
mutable_args[ 2 ] = NULL;
pathvalue = getenv( PATH );
if (pathvalue) {
int pathlen = strlen( pathvalue );
pathenv = malloc( 5 + pathlen + 1 );
if ( pathenv ) {
memcpy( pathenv, PATH=, 5 );
memcpy( pathenv + 5, pathvalue, pathlen + 1 );
}
}
envp[ 0 ] = pathenv;
envp[ 1 ] = NULL;
setbuf( stdout, NULL );
setbuf( stderr, NULL );
printf( Spawning %s with search in $PATH and a limited environment...\n,
args[ 0 ] );
ec = spawnvpe( _P_WAIT, args[ 0 ], args, envp );
printf( Exit code: %d\n\n, ec );
printf( Loading %s with search in $PATH and inherited environment...\n,
args[ 0 ] );
// The prototype in unistd.h differs from the one in process.h. The former
// does not promise to keep the pointers intact.
execvp( args[ 0 ], mutable_args );
ec = errno;
printf( Load error: %s (%d)\n, strerror( ec ), ec );
return ec;
}
C:\WORK.\exec.exe ..\echo.exe
Spawning ..\echo.exe with search in $PATH and a limited environment...
abc
Exit code: 0
Loading ..\echo.exe with search in $PATH and inherited environment...
Load error: No such file or directory (2)
C:\WORKcopy \cygwin\bin\cygwin1.dll.new \cygwin\bin\cygwin1.dll
Overwrite \cygwin\bin\cygwin1.dll? (Yes/No/All): y
1 file(s) copied.
C:\WORK.\exec.exe ..\echo.exe
Spawning ..\echo.exe with search in $PATH and a limited environment...
abc
Exit code: 0
Loading ..\echo.exe with search in $PATH and inherited environment...
abc
C:\WORK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: allow executing a path in backslash notation
On Mar 10 10:25, Corinna Vinschen wrote:
execv (argv[1], args);
bash$ gcc -o exec exec.c
bash$ ./exec /bin/echo
abc
bash$ ./exec C:\\cygwin\\bin\\echo
abc
Thanks for trying a test case. I am attaching a new test case that
shows that the trouble was with execvp(), not exec(). Only execvp()
calls find_exec() which fails to find a file in backslash notation,
find_exec (path, buf, PATH=, FE_NNF)
Another call to find_exec in spawnvpe() seems to succeed,
find_exec (file, buf)
So, perhaps, another way to address the issue is to call find_exec()
without the 2 extra parameters. I find it confusing that the
function did not work despite its numerous options and its usage of
isdrive() implying attempts to handle Windows native paths.
--
#include process.h// for spawnvpe() (not specified by The Open Group)
#include unistd.h // for execvp()
#include stdio.h // for printf()
#include errno.h // for errno
#include string.h // for strdup(), strerror()
#include stdlib.h // for getenv()
int
main (int argc, const char *argv[])
{
const char const *args[3];
char *mutable_args[3];
// See http://c-faq.com/ansi/constmismatch.html explaining that a promise
// of constness of values pointed to by pointer elements requires constness
// of pointers as well. In other words, a const char** parameter cannot
// accept a char ** argument.
const char *envp[2];
const char *pathvalue = NULL;
char *pathenv = NULL;
int ec;
if ( argc 2 ) {
return 2;
}
args[ 0 ] = argv[1];
args[ 1 ] = abc;
args[ 2 ] = NULL;
mutable_args[ 0 ] = strdup( args[ 0 ] );
mutable_args[ 1 ] = strdup( args[ 1 ] );
mutable_args[ 2 ] = NULL;
pathvalue = getenv( PATH );
if (pathvalue) {
int pathlen = strlen( pathvalue );
pathenv = malloc( 5 + pathlen + 1 );
if ( pathenv ) {
memcpy( pathenv, PATH=, 5 );
memcpy( pathenv + 5, pathvalue, pathlen + 1 );
}
}
envp[ 0 ] = pathenv;
envp[ 1 ] = NULL;
setbuf( stdout, NULL );
setbuf( stderr, NULL );
printf( Spawning %s with search in $PATH and a limited environment...\n,
args[ 0 ] );
ec = spawnvpe( _P_WAIT, args[ 0 ], args, envp );
printf( Exit code: %d\n\n, ec );
printf( Loading %s with search in $PATH and inherited environment...\n,
args[ 0 ] );
// The prototype in unistd.h differs from the one in process.h. The former
// does not promise to keep the pointers intact.
execvp( args[ 0 ], mutable_args );
ec = errno;
printf( Load error: %s (%d)\n, strerror( ec ), ec );
return ec;
}
C:\WORK.\exec.exe ..\echo.exe
Spawning ..\echo.exe with search in $PATH and a limited environment...
abc
Exit code: 0
Loading ..\echo.exe with search in $PATH and inherited environment...
Load error: No such file or directory (2)
C:\WORKcopy \cygwin\bin\cygwin1.dll.new \cygwin\bin\cygwin1.dll
Overwrite \cygwin\bin\cygwin1.dll? (Yes/No/All): y
1 file(s) copied.
C:\WORK.\exec.exe ..\echo.exe
Spawning ..\echo.exe with search in $PATH and a limited environment...
abc
Exit code: 0
Loading ..\echo.exe with search in $PATH and inherited environment...
abc
C:\WORK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: allow executing a path in backslash notation
constness of pointers Err, I meant constness of rvalue. But this is not related. -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug#549094: wodim: intermittent CHECK CONDITION followed by fixating
Package: wodim
Version: 9:1.1.10-1
Severity: normal
Perhaps, my issue is related. I am getting intermittent no error
errors displaying status: 0x02 (CHECK_CONDITION).
I suspect that an extra resid: 28 in addition to a regular resid: 8 is an
early indicator of the trouble.
As a result, the blank DVD-R disk gets its session closed and I cannot
use it for my single-session burning.
I am including a failure log. After making a coaster of 2 blank
disks, I then got the burning succeed. I include the log of the
successful cdrecord invocation after the failure log. I think both
wodim and cdrecord suffer from the intermittent failure I am describing.
===
il...@ei:~/download$ sudo wodim -v ${DISK_NAME}.iso
wodim: No write mode specified.
wodim: Assuming -tao mode.
wodim: Future versions of wodim may have different drive dependent defaults.
TOC Type: 1 = CD-ROM
Device was not specified. Trying to find an appropriate drive...
Looking for a DVD-R drive to store 4267.57 MiB...
Detected DVD-R drive: /dev/hdb
scsidev: '/dev/hdb'
devname: '/dev/hdb'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.10
SCSI buffer size: 64512
Device type: Removable CD-ROM
Version: 0
Response Format: 2
Capabilities :
Vendor_info: 'HL-DT-ST'
Identification : 'DVDRAM GSA-H10A '
Revision : 'JL03'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x0011 (DVD-R sequential recording)
Profile: 0x0012 (DVD-RAM)
Profile: 0x0011 (DVD-R sequential recording) (current)
Profile: 0x0015 (DVD-R/DL sequential recording)
Profile: 0x0016 (DVD-R/DL layer jump recording)
Profile: 0x0014 (DVD-RW sequential recording)
Profile: 0x0013 (DVD-RW restricted overwrite)
Profile: 0x001A (DVD+RW)
Profile: 0x001B (DVD+R)
Profile: 0x002B (DVD+R/DL)
Profile: 0x0010 (DVD-ROM)
Profile: 0x0009 (CD-R)
Profile: 0x000A (CD-RW)
Profile: 0x0008 (CD-ROM)
Profile: 0x0002 (Removable disk)
Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd).
Driver flags : SWABAUDIO BURNFREE
Supported modes: PACKET SAO
Drive buf size : 1114112 = 1088 KB
Beginning DMA speed test. Set CDR_NODMATEST environment variable if device
communication breaks or freezes immediately after that.
Drive DMA Speed: 14562 kB/s 82x CD 10x DVD
FIFO size : 12582912 = 12288 KB
Track 01: data 4267 MB
Total size: 4901 MB (485:33.25) = 2184994 sectors
Lout start: 4901 MB (485:35/19) = 2184994 sectors
Current Secsize: 2048
HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction.
Blocks total: 2298496 Blocks current: 2298496 Blocks remaining: 113502
Speed set to 22160 KB/s
Starting to write CD/DVD at speed 17.0 in real unknown mode for single session.
Last chance to quit, starting real write in0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
Performing OPC...
resid: 8
resid: 28
Starting new track at sector: 825831473
Track 01:0 of 4267 MB written.Errno: 0 (Success), write_g1 scsi sendcmd: no
error
CDB: 2A 00 31 39 30 31 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: F0 00 05 31 39 30 31 10 2A 00 00 0C 21 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x21 Qual 0x00 (logical block address out of range) Fru 0x0
Sense flags: Blk 825831473 (valid)
resid: 63488
cmd finished after 0.008s timeout 40s
write track data: error after 0 bytes
wodim: The current problem looks like a buffer underrun.
wodim: Try to use 'driveropts=burnfree'.
wodim: Make sure that you are root, enable DMA and check your HW/OS set up.
Writing time: 82.650s
Average write speed 111.0x.
Fixating...
Fixating time:5.964s
wodim: fifo had 192 puts and 1 gets.
wodim: fifo was 0 times empty and 0 times full, min fill was 100%.
===
il...@ei:~/download$ sudo cdrecord -vvv -tao ${DISK_NAME}.iso
TOC Type: 1 = CD-ROM
Device was not specified. Trying to find an appropriate drive...
Looking for a DVD-R drive to store 4267.57 MiB...
Detected DVD-R drive: /dev/hdb
scsidev: '/dev/hdb'
devname: '/dev/hdb'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.10
Using libusal version 'Cdrkit-1.1.10'.
SCSI buffer size: 64512
Device type: Removable CD-ROM
Version: 0
Response Format: 2
Capabilities :
Vendor_info: 'HL-DT-ST'
Identification : 'DVDRAM GSA-H10A '
Revision : 'JL03'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x0011 (DVD-R sequential recording)
Profile: 0x0012 (DVD-RAM)
Profile: 0x0011 (DVD-R sequential recording) (current)
Profile: 0x0015 (DVD-R/DL sequential recording)
Profile: 0x0016 (DVD-R/DL layer jump recording)
Profile: 0x0014 (DVD-RW sequential recording)
Profile: 0x0013 (DVD-RW restricted overwrite)
Profile: 0x001A (DVD+RW)
Profile: 0x001B (DVD+R)
Profile: 0x002B (DVD+R/DL)
Profile: 0x0010 (DVD-ROM)
Profile: 0x0009
Bug#549094: wodim: OPC failed; logical block address out of range
Package: wodim
Version: 9:1.1.10-1
Severity: normal
Forgot to add the dmesg output that might be related. Also, I just realized
that the sense code error message was logical block address out of range.
[ 4469.846681] hdb: command error: status=0x51 { DriveReady SeekComplete Error }
[ 4469.846694] hdb: command error: error=0x54 { AbortedCommand
LastFailedSense=0x05 }
[ 4469.846702] hdb: possibly failed opcode: 0xa0
[ 4469.849215] end_request: I/O error, dev hdb, sector 0
[ 4469.849221] Buffer I/O error on device hdb, logical block 0
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages wodim depends on:
ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib
ii libcap2 1:2.17-2 support for getting/setting POSIX.
Versions of packages wodim recommends:
ii genisoimage 9:1.1.10-1 Creates ISO-9660 CD-ROM filesystem
Versions of packages wodim suggests:
ii cdrkit-doc9:1.1.10-1 Documentation for the cdrkit packa
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: allow executing a path in backslash notation
The bottom line is that if you want to use MS-DOS paths, then use a MinGW or DJGPP version of make.exe. make.exe is not going to be patched. The patch was to cygwin1.dll, but I am not insisting. -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin build scripts in perl
In particular, mkimport ran objcopy against ftruncate.o in a
temporary directory, but I believe the expected filename argument was
supposed to be t-ftruncate.o. This is only my conjecture as I do not
know the purpose and the intention of the implementation with these
scripts.
While it is very possible that my code could have bugs, the objcopy
commands in the code exit on error so, if there were problems with the
commands no one would be able to build cygwin. I don't see any objcopy
errors when I build Cygwin on either linux or Windows.
I suspect that an assumption in mkimport does not always hold true. It appears
that the script assumes existence of SYMBOL.o members of the input library
cygdll.a for each object symbol SYMBOL being replaced.
if (!defined($fn = $symfile{$_sym})) {
$fn = $sym.o;
$text{$fn} = $_sym;
}
My linker created cygdll.a where all *.o members were in the form
d00[0-9]{4}.o
I guess the difference is in the GNU compiler version. I am using gcc 4.3.4-3
with --version showing 4.3.4 20090804 (release) 1. (Just in case, my
binutils are 2.19.51-1 with --version showing 2.19.51.20090704).
Let me take my original blind guess back. It probably resulted in a wrong
import library. I wonder if such mistakes like mine could be caught by
checking the contents of the generated import library.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
allow executing a path in backslash notation
The attached patch allows executing a path in backslash notation. This can be
tested in the Cygwin builds of GNU make with the DOS compatibility
compile-time option of GNU make enabled, such as those from Cygwin make
packages 3.79 and 3.80.
$ cat dos-compat.mak
default:
..\echo.exe test
C:\FULLPATH\echo.exe test
$ ./make.exe --win32 -f dos-compat.mak
..\echo.exe test
test
C:\FULLPATH\echo.exe test
test
The patch cannot be tested by simply running a command in backslash notation in
the existing Cygwin build of bash or pdksh because these shells re-implement
the search of the potential executable command. I believe these
re-implementations are for improved user interaction and platform-independent
security.
The patch is a blind conjecture because I am not fully aware about the
intention of find_exec() in spawn.cc. Its implementation seems exceedingly
complicated to me, and the comments in the middle of the function about
refusing a full Windows path contradict the description of the function above
its prototype.
-- Index: spawn.cc
===
RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v
retrieving revision 1.288
diff -u -r1.288 spawn.cc
--- spawn.cc25 Jan 2010 11:21:56 - 1.288
+++ spawn.cc9 Mar 2010 00:20:54 -
@@ -112,15 +112,16 @@
char *tmp = tp.c_get ();
const char *posix = (opt FE_NATIVE) ? NULL : name;
bool has_slash = strchr (name, '/');
+ bool has_backslash = strchr (name, '\\');
int err;
/* Check to see if file can be opened as is first.
Win32 systems always check . first, but PATH may not be set up to
do this. */
- if ((has_slash || opt FE_CWD)
+ if ((has_slash || has_backslash || opt FE_CWD)
(suffix = perhaps_suffix (name, buf, err, opt)) != NULL)
{
- if (posix !has_slash)
+ if (posix !has_slash !has_backslash)
{
tmp[0] = '.';
tmp[1] = '/';
@@ -147,7 +148,7 @@
path = s;
posix_path = mywinenv - 1;
}
- else if (has_slash || strchr (name, '\\') || isdrive (name)
+ else if (has_slash || has_backslash || isdrive (name)
|| !(winpath = getwinenv (mywinenv))
|| !(path = winpath-get_native ()) || *path == '\0')
/* Return the error condition if this is an absolute path or if there
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin build scripts in perl
It isn't clear from your email what you are attempting to accomplish but it sounds like you are trying to build cygwin using a non-cygwin-aware version of perl. If that is the case, then this is not of interest to the project or this mailing list. The build breaks were exposed by using the Windows native build of perl, but the root causes were not specific to the build kind of perl. In particular, mkimport ran objcopy against ftruncate.o in a temporary directory, but I believe the expected filename argument was supposed to be t-ftruncate.o. This is only my conjecture as I do not know the purpose and the intention of the implementation with these scripts. In another case of a build break, perl complained that the list form of pipe which I believe is the dash followed by pipe construct, was not implemented. Perhaps, the implementation is an option configured during the perl interpreter's build, but I found the use of a rare construct alarming and replaced it with a common construct. In the patch below many of the changes are either inexplicable or just whitespace so I haven't spent much time trying to figure out if there is a bug fix in there. I suspect that, since many people are building the Cygwin DLL, there can't be much of a problem. + die E: $0: $cmd_nm:\n$!\n; ^^ inexplicable prepending of E: to an error message. I apologize I forgot to explain the E: prefix as I thought its addition was not as important as fixing the build breaks. I figured that the E:, for error, and W:, for warning, prefixes may add some structure to the build output from the build system analysis viewpoint. - 'ar=s'=\$ar, 'as=s'=\$as,'nm=s'=\$nm, 'objcopy=s'=\$objcopy); + 'ar=s'=\$ar, 'as=s'=\$as,'nm=s'=\$nm, 'objcopy=s'=\$objcopy); gratuitous whitespace change The whitespace changes were to stop relying on the editor's settings by replacing all Tab characters with the appropriate amount of space characters. This was only a bundled change that I removed from the -nowhitespace.txt diffs. I provided the non-whitespace diffs beside the precise ones under the file names ending with -nowhitespace.txt. -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin build scripts in perl
(a) I found that winsup/cygwin/mkimport specified non-existent file names as
arguments to objcopy invocations. I am not sure why this did not cause build
breaks earlier.
(b) It appears perl 5.6 and, possibly, perl 5.10 do not implement the list
form of pipe in calls to open(),
open $my_fd, '-|', $cmd, $arg1, $arg2
I got around that by using regular pipes.
(c) The Windows native build of perl wrapped into a cygpath-translating script
/usr/bin/perl will require protection of drive letters when using a regex in
speclib. I believe this change may still work with Cygwin builds of perl.
I am not aware of the purpose of the two scripts that I modified, but the fixes
made my build succeed.
--
==
$ cat /usr/bin/perl
#! /bin/bash
args=()
for f ; do
if [ -f ${f} ] ; then
f=$(cygpath -w ${f})
f=${f#\?\\}
fi
args+=(${f})
done
set -x
exec /c/NATIVEPERL/perl.exe -Ic:/NATIVEPERL/lib ${ar...@]}
==Index: speclib
===
RCS file: /cvs/src/src/winsup/cygwin/speclib,v
retrieving revision 1.24
diff -d -u -r1.24 speclib
--- speclib 30 Nov 2009 15:40:23 - 1.24
+++ speclib 23 Feb 2010 23:18:37 -
@@ -13,7 +13,7 @@
my ($ar, $as, $nm, $objcopy);
GetOptions('exclude=s'=\...@exclude, 'static!'=\$static, 'v!'=\$inverse,
- 'ar=s'=\$ar, 'as=s'=\$as,'nm=s'=\$nm, 'objcopy=s'=\$objcopy);
+ 'ar=s'=\$ar, 'as=s'=\$as,'nm=s'=\$nm, 'objcopy=s'=\$objcopy);
$_ = File::Spec-rel2abs($_) for @ARGV;
@@ -22,8 +22,11 @@
(my $iname = basename $lib) =~ s/\.a$//o;
$iname = '_' . $iname . '_dll_iname';
-open my $nm_fd, '-|', $nm, '-Apg', '--defined-only', @ARGV, $libdll or
- die $0: execution of $nm for object files failed - $!\n;
+my $qargs = join( , map(\$_\, @ARGV));
+my $cmd_nm = $nm -Apg --defined-only $qargs \$libdll\;
+print Reading from $cmd_nm ...\n;
+open my $nm_fd, $cmd_nm | or
+ die E: $0: $cmd_nm:\n$!\n;
my %match_syms = ();
my $symfiles = ();
@@ -35,44 +38,47 @@
while ($nm_fd) {
study;
if (/ I _(.*)_dll_iname/o) {
- $dllname = $1;
+$dllname = $1;
} else {
- my ($file, $member, $symbol) = m%^([^:]*):([^:]*(?=:))?.* T (.*)%o;
- next if !defined($symbol) || $symbol =~ $exclude_regex;
- if ($file ne $libdll) {
-$match_syms{$symbol} = 1;
-} elsif ($match_syms{$symbol} ? !$inverse : $inverse) {
-$extract{$member} = 1;
-}
+my ($file, $member, $symbol) = m%^(.*?(?!:\\)):([^:]*:)?[0-9a-fA-F]{8}
T (.*)%o;
+next if !defined($symbol) || $symbol =~ $exclude_regex;
+if ($file ne $libdll) {
+$match_syms{$symbol} = 1;
+} elsif ($match_syms{$symbol} ? !$inverse : $inverse) {
+chop($member);
+$extract{$member} = 1;
+}
}
}
close $nm_fd;
-
-%extract or die $0: couldn't find symbols for $lib\n;
+%extract or die E: $0: couldn't find symbols for $lib\n;
my $dir = tempdir(CLEANUP = 1);
chdir $dir;
# print join(' ', '+', $ar, 'x', sort keys %extract), \n;
my $res = system $ar, 'x', $libdll, sort keys %extract;
-die $0: $ar extraction exited with non-zero status\n if $res;
+die E: $0: $ar extraction exited with non-zero status\n if $res;
unlink $lib;
# Add a dummy .idata object for libtool so that it will think
# this library is an import library.
my $iname_o = 'd00.o';
$extract{$iname_o} = 1;
-open my $as_fd, '|-', $as, '-R', '-o', $iname_o, -;
+my $cmd_as = $as -R -o $iname_o -;
+print Writing to $cmd_as ...\n;
+open my $as_fd, | $cmd_as or die E: $0: $cmd_as:\n$!\n;
print $as_fd EOF;
- .section .idata\$7
+.section .idata\$7
.global $iname
$iname: .asciz $dllname.dll
EOF
close $as_fd or exit 1;
-system $objcopy, '-j', '.idata$7', $iname_o;
+system $objcopy, '-j', '.idata$7', $iname_o and die E: $0: $objcopy:\n$!\n;
$res = system $ar, 'crus', $lib, sort keys %extract;
unlink keys %extract;
-die $0: ar creation of $lib exited with non-zero status\n if $res;
+die E: $0: ar creation of $lib exited with non-zero status\n if $res;
exit 0;
+
Index: speclib
===
RCS file: /cvs/src/src/winsup/cygwin/speclib,v
retrieving revision 1.24
diff -d -u -w -r1.24 speclib
--- speclib 30 Nov 2009 15:40:23 - 1.24
+++ speclib 23 Feb 2010 23:18:32 -
@@ -22,8 +22,11 @@
(my $iname = basename $lib) =~ s/\.a$//o;
$iname = '_' . $iname . '_dll_iname';
-open my $nm_fd, '-|', $nm, '-Apg', '--defined-only', @ARGV, $libdll or
- die $0: execution of $nm for object files failed - $!\n;
+my $qargs = join( , map(\$_\, @ARGV));
+my $cmd_nm = $nm -Apg --defined-only $qargs \$libdll\;
+print Reading from $cmd_nm ...\n;
+open my $nm_fd, $cmd_nm | or
+ die E: $0: $cmd_nm:\n$!\n;
my %match_syms = ();
my $symfiles = ();
@@ -37,42 +40,45
