Nightly build #338 for cordova has failed

[Apache Jenkins Server]

Nightly build #338 for cordova has failed.

Please check failure details on build details page at 
https://builds.apache.org/job/cordova-nightly/338/
You can also take a look at build console: 
https://builds.apache.org/job/cordova-nightly/338/consoleFull

-
Jenkins for Apache Cordova

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-lib issue #542: CB-12663: Install latest version of plugin in case o...

[uk-taniyama]

Github user uk-taniyama commented on the issue:

https://github.com/apache/cordova-lib/pull/542
  
I got same error.

```
Unmet project requirements for latest version of 
cordova-plugin-inappbrowser:
cordova (1.0.0 in project, >=3.1.0 required)
Fetching highest version of cordova-plugin-inappbrowser that this project 
supports: 0.2.2 (latest is 1.7.1)
```

This version '1.0.0' is written in my application's 
package.json.(@plugin.js determinePluginTarget)
So, I try to change package.json's version to '7.0.0' then success.

I think this version MUST be cordova's version.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[kerrishotts]

Github user kerrishotts commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115361265
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
+
+### Don't use eval()
+
+The JavaScript function eval() has a long history of being abused. Using 
it incorrectly can open your code up for injection attacks, debugging 
difficulties, and slower code execution.
+
+### Do not assume that your source code is secure
+
+Since a Cordova application is built from HTML and JavaScript assets that 
get packaged in a native container, you should not consider your code to be 
secure. It is possible to reverse engineer a Cordova application.
+
+A sampling of what you should not include in your code:
+
+* Authentication information (usernames, passwords, keys, etc.)
+* Encryption keys
+* Trade secrets
+
+### Do not assume storage containers are secure
+
+Even if a device itself is encrypted, if someone has access to the device 
and can unlock it, you should not assume that data stored in various formats 
and containers is safe. Even SQLite databases are easily human readable once 
access is gained.
+
+As long as you're storing non-sensitive information, this isn't a big 
deal. But if you were storing passwords, keys, and other sensitive information, 
the data could be easily extracted, and depending on what was stored, could be 
used against your app and remote servers.
+
+For example, on iOS, if you store data in `localStorage`, the data itself 
is easily readable to anyone who has access to the device. This is because 
`localStorage` is backed by an unencrypted SQLite database. The underlying 
storage of the device may in fact be encrypted (and so it would be inaccessible 
while the device is locked), but once the device decrypts the file, the 
contents themselves are mostly in the clear. As such, the contents of 
`localStorage` can be easily read and even changed.
+
+## Plugins and Security
+
+Due to the way the native portion of Cordova communicates with your web 
code, it is possible for any code executing within the main webview context to 
communicate with any installed plugins. This means that you should _never_ 
permit untrusted content within the primary webview. This can include 
third-party advertisements, sites within an `iframe`, and even content injected 
via `innerHTML`.
+
+If you must inject content into the primary webview, be certain that it 
has been 

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[jcesarmobile]

Github user jcesarmobile commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115360483
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
+
+### Don't use eval()
+
+The JavaScript function eval() has a long history of being abused. Using 
it incorrectly can open your code up for injection attacks, debugging 
difficulties, and slower code execution.
+
+### Do not assume that your source code is secure
+
+Since a Cordova application is built from HTML and JavaScript assets that 
get packaged in a native container, you should not consider your code to be 
secure. It is possible to reverse engineer a Cordova application.
+
+A sampling of what you should not include in your code:
+
+* Authentication information (usernames, passwords, keys, etc.)
+* Encryption keys
+* Trade secrets
+
+### Do not assume storage containers are secure
+
+Even if a device itself is encrypted, if someone has access to the device 
and can unlock it, you should not assume that data stored in various formats 
and containers is safe. Even SQLite databases are easily human readable once 
access is gained.
+
+As long as you're storing non-sensitive information, this isn't a big 
deal. But if you were storing passwords, keys, and other sensitive information, 
the data could be easily extracted, and depending on what was stored, could be 
used against your app and remote servers.
+
+For example, on iOS, if you store data in `localStorage`, the data itself 
is easily readable to anyone who has access to the device. This is because 
`localStorage` is backed by an unencrypted SQLite database. The underlying 
storage of the device may in fact be encrypted (and so it would be inaccessible 
while the device is locked), but once the device decrypts the file, the 
contents themselves are mostly in the clear. As such, the contents of 
`localStorage` can be easily read and even changed.
+
+## Plugins and Security
+
+Due to the way the native portion of Cordova communicates with your web 
code, it is possible for any code executing within the main webview context to 
communicate with any installed plugins. This means that you should _never_ 
permit untrusted content within the primary webview. This can include 
third-party advertisements, sites within an `iframe`, and even content injected 
via `innerHTML`.
+
+If you must inject content into the primary webview, be certain that it 
has been 

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[kerrishotts]

Github user kerrishotts commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115358538
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
+
+### Don't use eval()
+
+The JavaScript function eval() has a long history of being abused. Using 
it incorrectly can open your code up for injection attacks, debugging 
difficulties, and slower code execution.
+
+### Do not assume that your source code is secure
+
+Since a Cordova application is built from HTML and JavaScript assets that 
get packaged in a native container, you should not consider your code to be 
secure. It is possible to reverse engineer a Cordova application.
+
+A sampling of what you should not include in your code:
+
+* Authentication information (usernames, passwords, keys, etc.)
+* Encryption keys
+* Trade secrets
+
+### Do not assume storage containers are secure
+
+Even if a device itself is encrypted, if someone has access to the device 
and can unlock it, you should not assume that data stored in various formats 
and containers is safe. Even SQLite databases are easily human readable once 
access is gained.
+
+As long as you're storing non-sensitive information, this isn't a big 
deal. But if you were storing passwords, keys, and other sensitive information, 
the data could be easily extracted, and depending on what was stored, could be 
used against your app and remote servers.
+
+For example, on iOS, if you store data in `localStorage`, the data itself 
is easily readable to anyone who has access to the device. This is because 
`localStorage` is backed by an unencrypted SQLite database. The underlying 
storage of the device may in fact be encrypted (and so it would be inaccessible 
while the device is locked), but once the device decrypts the file, the 
contents themselves are mostly in the clear. As such, the contents of 
`localStorage` can be easily read and even changed.
+
+## Plugins and Security
+
+Due to the way the native portion of Cordova communicates with your web 
code, it is possible for any code executing within the main webview context to 
communicate with any installed plugins. This means that you should _never_ 
permit untrusted content within the primary webview. This can include 
third-party advertisements, sites within an `iframe`, and even content injected 
via `innerHTML`.
+
+If you must inject content into the primary webview, be certain that it 
has been 

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[kerrishotts]

Github user kerrishotts commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115358440
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
+
+### Don't use eval()
+
+The JavaScript function eval() has a long history of being abused. Using 
it incorrectly can open your code up for injection attacks, debugging 
difficulties, and slower code execution.
+
+### Do not assume that your source code is secure
+
+Since a Cordova application is built from HTML and JavaScript assets that 
get packaged in a native container, you should not consider your code to be 
secure. It is possible to reverse engineer a Cordova application.
+
+A sampling of what you should not include in your code:
+
+* Authentication information (usernames, passwords, keys, etc.)
+* Encryption keys
+* Trade secrets
+
+### Do not assume storage containers are secure
+
+Even if a device itself is encrypted, if someone has access to the device 
and can unlock it, you should not assume that data stored in various formats 
and containers is safe. Even SQLite databases are easily human readable once 
access is gained.
+
+As long as you're storing non-sensitive information, this isn't a big 
deal. But if you were storing passwords, keys, and other sensitive information, 
the data could be easily extracted, and depending on what was stored, could be 
used against your app and remote servers.
+
+For example, on iOS, if you store data in `localStorage`, the data itself 
is easily readable to anyone who has access to the device. This is because 
`localStorage` is backed by an unencrypted SQLite database. The underlying 
storage of the device may in fact be encrypted (and so it would be inaccessible 
while the device is locked), but once the device decrypts the file, the 
contents themselves are mostly in the clear. As such, the contents of 
`localStorage` can be easily read and even changed.
+
+## Plugins and Security
+
+Due to the way the native portion of Cordova communicates with your web 
code, it is possible for any code executing within the main webview context to 
communicate with any installed plugins. This means that you should _never_ 
permit untrusted content within the primary webview. This can include 
third-party advertisements, sites within an `iframe`, and even content injected 
via `innerHTML`.
+
+If you must inject content into the primary webview, be certain that it 
has been 

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[kerrishotts]

Github user kerrishotts commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115358385
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
+
+### Don't use eval()
+
+The JavaScript function eval() has a long history of being abused. Using 
it incorrectly can open your code up for injection attacks, debugging 
difficulties, and slower code execution.
+
+### Do not assume that your source code is secure
+
+Since a Cordova application is built from HTML and JavaScript assets that 
get packaged in a native container, you should not consider your code to be 
secure. It is possible to reverse engineer a Cordova application.
+
+A sampling of what you should not include in your code:
+
+* Authentication information (usernames, passwords, keys, etc.)
+* Encryption keys
+* Trade secrets
+
+### Do not assume storage containers are secure
+
+Even if a device itself is encrypted, if someone has access to the device 
and can unlock it, you should not assume that data stored in various formats 
and containers is safe. Even SQLite databases are easily human readable once 
access is gained.
+
+As long as you're storing non-sensitive information, this isn't a big 
deal. But if you were storing passwords, keys, and other sensitive information, 
the data could be easily extracted, and depending on what was stored, could be 
used against your app and remote servers.
+
+For example, on iOS, if you store data in `localStorage`, the data itself 
is easily readable to anyone who has access to the device. This is because 
`localStorage` is backed by an unencrypted SQLite database. The underlying 
storage of the device may in fact be encrypted (and so it would be inaccessible 
while the device is locked), but once the device decrypts the file, the 
contents themselves are mostly in the clear. As such, the contents of 
`localStorage` can be easily read and even changed.
+
+## Plugins and Security
+
+Due to the way the native portion of Cordova communicates with your web 
code, it is possible for any code executing within the main webview context to 
communicate with any installed plugins. This means that you should _never_ 
permit untrusted content within the primary webview. This can include 
third-party advertisements, sites within an `iframe`, and even content injected 
via `innerHTML`.
+
+If you must inject content into the primary webview, be certain that it 
has been 

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[kerrishotts]

Github user kerrishotts commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115357887
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
+
+### Don't use eval()
+
+The JavaScript function eval() has a long history of being abused. Using 
it incorrectly can open your code up for injection attacks, debugging 
difficulties, and slower code execution.
+
+### Do not assume that your source code is secure
+
+Since a Cordova application is built from HTML and JavaScript assets that 
get packaged in a native container, you should not consider your code to be 
secure. It is possible to reverse engineer a Cordova application.
--- End diff --

Mmm -- I like that much better. :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[kerrishotts]

Github user kerrishotts commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115357795
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
--- End diff --

Yes, this needs to be worded better and have some concrete examples. :-) I 
think "caching" is the wrong word here (this was copied from the previous 
version) -- "store" is probably more accurate.

I _think_ attacks would either have to be device-in-hand attacks (since 
you'd need to get into the file system -- that's when you hope the device is 
protected with a pin & is encrypted!) or malware / viruses that abused some 
security hole (or ran amuck on a rooted/JB'd device). OR, if the app stored 
data in a public area on the file system (say, on Android), that would be risky 
too. (Hopefully no one would do that, though...!) So yes... more examples of 
what is meant by this would be good.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[filmaj]

Github user filmaj commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115321603
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
+
+### Don't use eval()
+
+The JavaScript function eval() has a long history of being abused. Using 
it incorrectly can open your code up for injection attacks, debugging 
difficulties, and slower code execution.
+
+### Do not assume that your source code is secure
+
+Since a Cordova application is built from HTML and JavaScript assets that 
get packaged in a native container, you should not consider your code to be 
secure. It is possible to reverse engineer a Cordova application.
+
+A sampling of what you should not include in your code:
+
+* Authentication information (usernames, passwords, keys, etc.)
+* Encryption keys
+* Trade secrets
+
+### Do not assume storage containers are secure
+
+Even if a device itself is encrypted, if someone has access to the device 
and can unlock it, you should not assume that data stored in various formats 
and containers is safe. Even SQLite databases are easily human readable once 
access is gained.
+
+As long as you're storing non-sensitive information, this isn't a big 
deal. But if you were storing passwords, keys, and other sensitive information, 
the data could be easily extracted, and depending on what was stored, could be 
used against your app and remote servers.
+
+For example, on iOS, if you store data in `localStorage`, the data itself 
is easily readable to anyone who has access to the device. This is because 
`localStorage` is backed by an unencrypted SQLite database. The underlying 
storage of the device may in fact be encrypted (and so it would be inaccessible 
while the device is locked), but once the device decrypts the file, the 
contents themselves are mostly in the clear. As such, the contents of 
`localStorage` can be easily read and even changed.
+
+## Plugins and Security
+
+Due to the way the native portion of Cordova communicates with your web 
code, it is possible for any code executing within the main webview context to 
communicate with any installed plugins. This means that you should _never_ 
permit untrusted content within the primary webview. This can include 
third-party advertisements, sites within an `iframe`, and even content injected 
via `innerHTML`.
+
+If you must inject content into the primary webview, be certain that it 
has been properly 

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[filmaj]

Github user filmaj commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115322154
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
+
+### Don't use eval()
+
+The JavaScript function eval() has a long history of being abused. Using 
it incorrectly can open your code up for injection attacks, debugging 
difficulties, and slower code execution.
+
+### Do not assume that your source code is secure
+
+Since a Cordova application is built from HTML and JavaScript assets that 
get packaged in a native container, you should not consider your code to be 
secure. It is possible to reverse engineer a Cordova application.
+
+A sampling of what you should not include in your code:
+
+* Authentication information (usernames, passwords, keys, etc.)
+* Encryption keys
+* Trade secrets
+
+### Do not assume storage containers are secure
+
+Even if a device itself is encrypted, if someone has access to the device 
and can unlock it, you should not assume that data stored in various formats 
and containers is safe. Even SQLite databases are easily human readable once 
access is gained.
+
+As long as you're storing non-sensitive information, this isn't a big 
deal. But if you were storing passwords, keys, and other sensitive information, 
the data could be easily extracted, and depending on what was stored, could be 
used against your app and remote servers.
+
+For example, on iOS, if you store data in `localStorage`, the data itself 
is easily readable to anyone who has access to the device. This is because 
`localStorage` is backed by an unencrypted SQLite database. The underlying 
storage of the device may in fact be encrypted (and so it would be inaccessible 
while the device is locked), but once the device decrypts the file, the 
contents themselves are mostly in the clear. As such, the contents of 
`localStorage` can be easily read and even changed.
+
+## Plugins and Security
+
+Due to the way the native portion of Cordova communicates with your web 
code, it is possible for any code executing within the main webview context to 
communicate with any installed plugins. This means that you should _never_ 
permit untrusted content within the primary webview. This can include 
third-party advertisements, sites within an `iframe`, and even content injected 
via `innerHTML`.
+
+If you must inject content into the primary webview, be certain that it 
has been properly 

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[filmaj]

Github user filmaj commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115322501
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
+
+### Don't use eval()
+
+The JavaScript function eval() has a long history of being abused. Using 
it incorrectly can open your code up for injection attacks, debugging 
difficulties, and slower code execution.
+
+### Do not assume that your source code is secure
+
+Since a Cordova application is built from HTML and JavaScript assets that 
get packaged in a native container, you should not consider your code to be 
secure. It is possible to reverse engineer a Cordova application.
+
+A sampling of what you should not include in your code:
+
+* Authentication information (usernames, passwords, keys, etc.)
+* Encryption keys
+* Trade secrets
+
+### Do not assume storage containers are secure
+
+Even if a device itself is encrypted, if someone has access to the device 
and can unlock it, you should not assume that data stored in various formats 
and containers is safe. Even SQLite databases are easily human readable once 
access is gained.
+
+As long as you're storing non-sensitive information, this isn't a big 
deal. But if you were storing passwords, keys, and other sensitive information, 
the data could be easily extracted, and depending on what was stored, could be 
used against your app and remote servers.
+
+For example, on iOS, if you store data in `localStorage`, the data itself 
is easily readable to anyone who has access to the device. This is because 
`localStorage` is backed by an unencrypted SQLite database. The underlying 
storage of the device may in fact be encrypted (and so it would be inaccessible 
while the device is locked), but once the device decrypts the file, the 
contents themselves are mostly in the clear. As such, the contents of 
`localStorage` can be easily read and even changed.
+
+## Plugins and Security
+
+Due to the way the native portion of Cordova communicates with your web 
code, it is possible for any code executing within the main webview context to 
communicate with any installed plugins. This means that you should _never_ 
permit untrusted content within the primary webview. This can include 
third-party advertisements, sites within an `iframe`, and even content injected 
via `innerHTML`.
+
+If you must inject content into the primary webview, be certain that it 
has been properly 

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[filmaj]

Github user filmaj commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115320846
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
--- End diff --

I feel like this statement is a little alarmist without providing concrete 
examples. It would also depend on what one means by "caching." Have you seen or 
heard of instances of this kind of attack happening in Cordova apps?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[filmaj]

Github user filmaj commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/703#discussion_r115321095
  
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -27,69 +27,155 @@ description: Information and tips for building a 
secure application.
 The following guide includes some security best practices that you should 
consider when developing a Cordova application. Please be aware that security 
is a very complicated topic and therefore this guide is not exhaustive. If you 
believe you can contribute to this guide, please feel free to file an issue in 
Cordova's bug tracker under 
["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407). 
 This guide is designed to be applicable to general Cordova development (all 
platforms) but special platform-specific considerations will be noted.
 
 ## This guide discusses the following topics:
+
+* General Tips
+* Plugins and Security
+* Content Security Policy
 * Whitelist
-* Iframes and the Callback Id Mechanism
 * Certificate Pinning
 * Self-signed Certificates
+* Wrapping external sites and hot code push
 * Encrypted storage
-* General Tips
 * Recommended Articles and Other Resources
 
+## General Tips
+
+### Use InAppBrowser for outside links
+
+Use the InAppBrowser when opening links to any outside website. This is 
much safer than whitelisting a domain name and including the content directly 
in your application because the InAppBrowser will use the native browser's 
security features and will not give the website access to your Cordova 
environment. Even if you trust the third party website and include it directly 
in your application, that third party website could link to malicious web 
content.
+
+### Validate all user input
+
+Always validate any and all input that your application accepts. This 
includes usernames, passwords, dates, uploaded media, etc. Because an attacker 
could manipulate your HTML and JS assets (either by decompiling your 
application or using debugging tools like `chrome://inspect`), this validation 
should also be performed on your server, especially before handing the data off 
to any backend service.
+
+> **Tip**: Other sources where data should be validated: user documents, 
contacts, push notifications
+
+### Do not cache sensitive data
+
+If usernames, password, geolocation information, and other sensitive data 
is cached, then it could potentially be retrieved later by an unauthorized user 
or application.
+
+### Don't use eval()
+
+The JavaScript function eval() has a long history of being abused. Using 
it incorrectly can open your code up for injection attacks, debugging 
difficulties, and slower code execution.
+
+### Do not assume that your source code is secure
+
+Since a Cordova application is built from HTML and JavaScript assets that 
get packaged in a native container, you should not consider your code to be 
secure. It is possible to reverse engineer a Cordova application.
--- End diff --

Maybe we can qualify the "it is possible to reverse engineer a Cordova app" 
statement? E.g. "an iOS or Android application can be simply unpacked and 
unzipped to reveal its web assets such as HTML and JS."


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Nightly build #337 for cordova has failed

[Apache Jenkins Server]

Nightly build #337 for cordova has failed.

Please check failure details on build details page at 
https://builds.apache.org/job/cordova-nightly/337/
You can also take a look at build console: 
https://builds.apache.org/job/cordova-nightly/337/consoleFull

-
Jenkins for Apache Cordova

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Nightly build #336 for cordova has failed

[Apache Jenkins Server]

Nightly build #336 for cordova has failed.

Please check failure details on build details page at 
https://builds.apache.org/job/cordova-nightly/336/
You can also take a look at build console: 
https://builds.apache.org/job/cordova-nightly/336/consoleFull

-
Jenkins for Apache Cordova

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Nightly build #335 for cordova has failed

[Apache Jenkins Server]

Nightly build #335 for cordova has failed.

Please check failure details on build details page at 
https://builds.apache.org/job/cordova-nightly/335/
You can also take a look at build console: 
https://builds.apache.org/job/cordova-nightly/335/consoleFull

-
Jenkins for Apache Cordova

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Nightly build #334 for cordova has failed

[Apache Jenkins Server]

Nightly build #334 for cordova has failed.

Please check failure details on build details page at 
https://builds.apache.org/job/cordova-nightly/334/
You can also take a look at build console: 
https://builds.apache.org/job/cordova-nightly/334/consoleFull

-
Jenkins for Apache Cordova

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

[kerrishotts]

GitHub user kerrishotts opened a pull request:

https://github.com/apache/cordova-docs/pull/703

CB-12770: revise security documentation

This is a *rough* first pass at revising the security documentation. 
Comments are very welcome!

** NOT READY FOR MERGE YET **

### What does this PR do?

Update security documentation

### Checklist
- [X] [Reported an issue](http://cordova.apache.org/contribute/issues.html) 
in the JIRA database
- [X] Commit message follows the format: "CB-3232: (android) Fix bug with 
resolving file paths", where CB- is the JIRA ID & "android" is the platform 
affected.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kerrishotts/cordova-docs CB-12770

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-docs/pull/703.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #703


commit 012f3f92e5bf1d4394b0d50f0f2e2bc7d2982bcc
Author: Kerri Shotts 
Date:   2017-05-08T15:19:19Z

CB-12770: revise security documentation




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-camera issue #230: CB-6708: [iOS]keep the metadata of image, ...

[mattss]

Github user mattss commented on the issue:

https://github.com/apache/cordova-plugin-camera/pull/230
  
Is there any update on getting this merged?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[Vote] Tools Release

[Steven Gill]

Please review and vote on this Tools Release
by replying to this email (and keep discussion on the DISCUSS thread)

Release issue: https://issues.apache.org/jira/browse/CB-12769

Tools have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12769/

The packages were published from their corresponding git tags:

cordova-lib: 7.0.1 (5a4c43c269)
cordova-cli: 7.0.1 (ba013489e2)
cordova-create: 1.1.1 (19e68bc187)

Upon a successful vote I will upload the archives to dist/, publish
them to npm, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses
* Ensured continuous build was green when repos were tagged

[GitHub] cordova-lib pull request #552: CB-12757 : Was previously saving wrong spec i...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-lib/pull/552


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-wkwebview-engine pull request #30: Allow XHR to file:// and a...

[rubenstolk]

Github user rubenstolk closed the pull request at:

https://github.com/apache/cordova-plugin-wkwebview-engine/pull/30


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-wkwebview-engine issue #30: Allow XHR to file:// and allow lo...

[rubenstolk]

Github user rubenstolk commented on the issue:

https://github.com/apache/cordova-plugin-wkwebview-engine/pull/30
  
Hey really cool!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-inappbrowser issue #213: CB-12468 added ability to set|get de...

[olgakozoriz]

Github user olgakozoriz commented on the issue:

https://github.com/apache/cordova-plugin-inappbrowser/pull/213
  
Have the same issue on IOS. Probably fixing ios is needed to, but seems 
that it's good workaround compatible with all systems. Why not merge?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org