Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
CI/CD / Security

Jenkins Security Updates Fix Three High-Risk Vulnerabilities

Oct 18th, 2017 11:05am by
Featued image for: Jenkins Security Updates Fix Three High-Risk Vulnerabilities

Jenkins has fixed a set of vulnerabilities, including one potentially over a year old, that left its users at risk of an attack on their internal systems.

Newly released versions of Jenkins address 11 vulnerabilities in the server’s core and plugins, including three vulnerabilities that are rated as high-risk and could result in arbitrary code or command execution.

Users are strongly advised to upgrade to Jenkins 2.84 or 2.73.2 and to install the latest versions of the Swarm and Maven plugins, namely Swarm Plugin (Client) version 3.5 and Maven Plugin version 3.0. Users of the Speaks! plugin are advised to uninstall it because it has a serious security issue for which there’s currently no fix.

The most serious vulnerability affects the Jenkins core and could allow users with Agent-related permissions to execute arbitrary shell commands on Jenkins master nodes.

The flaw could be exploited by users with the permission to create or configure agents by configuring a launch method called “Launch agent via execution of command on master.” The method could include arbitrary shell commands that would be executed when the agent is launched.

It took the Jenkins developers over a year to realize that they’re shipping a vulnerable version of the library.

Security researchers have previously warned that continuous integration tools like Jenkins have poor security out of the box and can help hackers break into organizations. Security researcher and penetration tester Nikhil Mittal presented several attacks against multiple CI tools — both open-source and proprietary — at the Black Hat Europe conference in 2015. He found default insecure configurations and exploitable features in all of them, prompting him to call them continuous intrusion tools.

Mittal warned at the time that the compromise of a CI tool can often result in administrative access to the whole network domain because chances are high that an administrator token can be extracted from processes running on CI machines. A video of his presentation is here.


The Jenkins developers have now restricted the use of this launch method to users with the Run Scripts permission — typically only granted to administrators.

“A known limitation of this fix is that users without the Run Scripts permission are no longer able to configure agents with this launch method at all, even if the launch method remains unchanged,” the Jenkins developers said in an advisory. “A future release of Jenkins will move this launch method into a separate plugin. That plugin will depend on Script Security Plugin to secure this field and restore the ability of users without the Run Scripts permission to configure an agent with this launch method.”

Another high-risk vulnerability patched in the new Jenkins releases actually stems from the bundled Apache Commons Fileupload library (commons-fileupload). What’s interesting is that this flaw was fixed in Apache Commons Fileupload back in June 2016.

This means it took the Jenkins developers over a year to realize that they’re shipping a vulnerable version of the library. This is a widespread problem with many developers failing to keep track of vulnerabilities in the third-party libraries and components they use.

The commons-fileupload vulnerability, CVE-2016-3092, can be exploited via malicious file upload requests to consume a server’s CPU resources, leading to a denial-of-service condition where the server becomes unable to service other users.

The Jenkins core also bundled a version of the commons-httpclient library with a vulnerability that was patched in 2012. The flaw, identified as CVE-2012-6153, causes the library to incorrectly validate SSL certificates, making traffic susceptible to man-in-the-middle attacks.

“This library is widely used as a transitive dependency in Jenkins plugins,” the Jenkins team warned. For example, the Maven and Swarm plugins also bundled an outdated commons-httpclient version vulnerable to the same flaw.

Another high-risk vulnerability was identified in the Speaks! plugin. It allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating their privileges to Overall/Run Scripts, the Jenkins developers said.

There is currently no fix for this flaw, which is why the Jenkins team has suspended the plugin’s distribution and recommends uninstalling it.

The other vulnerabilities patched in the new Jenkins releases are information disclosure issues in various remote APIs: User, Computer, Job and Queue Item.

Feature image via Pixabay.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.