mreinstein / alexa-verifier

✓ Verify HTTP requests sent to an Alexa skill are sent from Amazon

alexa-verifier

Verify HTTP requests sent to an Alexa skill are sent from Amazon.

This module is framework-agnostic.

If you're using expressjs, you should check out alexa-verifier-middleware which is a lot easier to integrate.

motivation

Part of the certication process for alexa skills hosted on a generic web service (i.e., not AWS Lambda) is that your skill must validate requests are actually coming from Amazon. This is enforced by checking:

• the timestamp of the request
• the validity of the certificate
• the signature of the the request signed with the aforementioned certificate

This module provides a function to handle this validation.

usage

arguments

• cert_url full url of the certificate to verify (from HTTP request header named signaturecertchainurl)
• signature signature of the request (from HTTP request header named signature)
• requestRawBody full body string from POST request
• callback (optional) completion function. has 1 argument which indicates error. falsey when verification passes

You may include a callback function, in the standard node error argument-first format:

import verifier from 'alexa-verifier'


verifier(cert_url, signature, requestRawBody, function callbackFn (er) {
    // if er, something went wrong
})

Ommiting a callback function returns a promise:

const verifyPromise = verifier(cert_url, signature, requestRawBody)

alexa-verifier's Issues

Support for promises (and wrapper included in comment)

Would be great for this to natively support promises. After looking through the code it wouldn't take much work to add support for it. In the meantime, if you would like to use this library as a promise, you can use the following wrapper.

const verifier = require('alexa-verifier');

const verifyRequest = (signatureCertUrl, signature, body) => {
  return new Promise((resolve, reject) => {
    verifier(signatureCertUrl, signature, body, (err) => {
      if (err) {
        return reject(err);
      };

      return resolve(body);
    });
  });
};

verifyRequest(req.headers.signaturecertchainurl, req.headers.signature, body)
  .then((body) => console.log('Success', body))
  .catch((err) => console.log('Error', err));

The skill end-point is not accepting valid signed requests.

Hosting skill on Heroku always receiving this last issue. I've tried using both this verifier and the alexa-verifier-middleware but no luck.

What is signature and where can I generate or assign

Sorry if this is a lame question because I am new to this aws field anyway Use of this we have to pass vairaboes as cert_url and signature.
When we can use https://s3.amazonaws.com/echo.api/echo-api-cert.pem as a cert_url
but I have a question where can I get the signature or how can I generate or assign.

Support for Cortana

As part of Cortana's skills kit, developers can reuse code from their existing Alexa Skills. It'd be great if this library supported verification of Cortana requests as well. The verification process is similar, so the core logic shouldn't change much.

Caching certificates to /tmp opens up a security problem?

See https://github.com/mreinstein/alexa-verifier/blob/master/index.js#L29

Isn't this opening up a security problem? The file could be (over)written by another program, for example to replace it with another certificate.

To be on the safe side, I would just avoid caching it on disk, but just keep an in-memory cache.

Thoughts?

Not working with azure functions

Hi,

I'm trying this module on a Windows 10 machine and I always get 'invalid signature' error.

Here is how I'm trying to use it.
Once I get the request, I extract the parameters in the following way

            let headers = request.headers;
            let signatureField;
            if("SignatureCertChainUrl" in headers) signatureField = "SignatureCertChainUrl";
            if("signaturecertchainurl" in headers) signatureField = "signaturecertchainurl";
            let cert_url = headers[signatureField];
            let signature = headers.signature;
            let requestRawBody = JSON.stringify(request.body);

Then I call the promise method with the following params

            verifier(cert_url, signature, requestRawBody).then((res) => {
                resolve(true);
            }).catch((err) => {
                resolve(false);
            })

I get that it goes always in catch with the error: 'invalid signature'

Sorry for having poorly documented the issue before.

Thanks for the patience

Feature request: easy middleware option

I wanted to suggest a feature that presents a middleware option for those who are using Express.js for their Alexa skill. You would still be able to keep the original functionality.

I've actually created a node module of my own called alexa-verifier-middleware, which essentially wraps the function you've provided in the example into a module.

Code Example:

var avm = require('alexa-verifier-middleware');
...
var app = express();
app.use(avm());

It would be nice if you can incorporate this feature into your module so that it would be easier for new developers to add request verification to their Alexa skills and I wouldn't need to maintain my module for the sake of simplicity.

Any way to get more details on failure?

I'm trying to get this working in OpenWhisk, using Node 6, and I'm getting:

certificate verification failed

I'm pretty sure the issue is the OpenWhisk platform and not your code, but is there anyway to get more details about what went wrong so I can dig deeper?

Missing validating certificate against a root CA certificate

Currently there is no verification that the downloaded certificate can be trusted, and the certificate is being taken at face value. This is critical in verification and is called out in Amazon's documentation:

All certificates in the chain combine to create a chain of trust to a trusted root CA certificate.

Reference: https://developer.amazon.com/docs/custom-skills/host-a-custom-skill-as-a-web-service.html#checking-the-signature-of-the-request

Update to Alexa Certificate

Hi,

Sorry if this is an ignorant question. I received a notification from Amazon regarding an update to their certificate. Will this module continue to work after the switch? Or is there something else I need to do one my end.

We are replacing the certificate that Alexa uses to sign https requests on June 28, 2018. To ensure that your skill will continue to operate uninterrupted, please verify that:

• Your endpoint certificate checks are not pinned in code.
• Your endpoint accepts of the Amazons Trust Services Certificate Authority (CA).
• You are following the guidelines outlined in our technical documentation.

An in-range update of request is breaking the build 🚨

Version 2.82.0 of request just got published.

Branch	Build failing 🚨
Dependency	request
Current Version	2.81.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

request is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

---

Commits

The new version differs by 27 commits.

• 0ab5c36 2.82.0
• ffdf0d3 Updating deps.
• 4386836 Merge branch 'master' of github.com:request/request
• 1527407 Merge pull request #2703 from ryysud/add-nodejs-v8-to-travis
• 3afcbf8 Merge branch 'master' of github.com:request/request
• 479143d Update of hawk and qs to latest version (#2751)
• 169be11 Add Node.js v8 to Travis CI
• 643c43a Fixed some text in README.md (#2658)
• e8fca51 chore(package): update aws-sign2 to version 0.7.0 (#2635)
• e999203 Update README to simplify & update convenience methods (#2641)
• 6f286c8 lint fix, PR from pre-standard was merged with passing tests
• a765593 Add convenience method for HTTP OPTIONS (#2541)
• 52d6945 Add promise support section to README (#2605)
• b12a624 refactor(lint): replace eslint with standard (#2579)
• 29a0b17 Merge pull request #2598 from request/greenkeeper-codecov-2.0.2

There are 27 commits in total.

See the full diff

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

Add URL validation to the library?

The first step in verifying the request, listed on the amazon site is verifying the certificate URL. To make this library more complete that could be added.

• The protocol is equal to https (case insensitive).
• The hostname is equal to s3.amazonaws.com (case insensitive).
• The path starts with /echo.api/ (case sensitive).
• If a port is defined in the URL, the port is equal to 443.

v3

Here's what I'm thinking about for the next major release (3.0.0):

• require node v12.17 and up
• switch to pure es module
• drop commonjs
• switch to es6 everywhere (const, let, spread, destructuring, etc.)
• ditch old callback style in favor of async function (finally!)
• update all deps

These are just my current musings. Open for thoughts/ideas/suggestions.

Certificate check fails when requests originate from the Alexa Developer Console

This is a follow-up to my issue reported on alexa/alexa-skills-kit-sdk-for-nodejs/issues/533

I'm using alexa-verifier to handle signature verification. But checks are failing when requests originate from the Alexa Developer Console.

I'm not sure if this issue is related to alexa-verifier or Alexa backend. Alexa team is investigating the issue on their end but having an extra set of eyes on it would be greatly appreciated.

My Alexa skill is open source so feel free to fork it if you want to reproduce the issue.

Tests should mock fetching the public certificate when testing primary functionality

I've noticed that the tests in test/index.js mostly don't mock fetching the certificate from the URL, which can lead to flaky tests. I recommend adding mocking functionality (similar to how you used nock in test/fetch-cert.js).

Error: write EPIPE

I am getting an exception trying to verify the certificate chain. Below is the stack trace.

events.js:141
throw er; // Unhandled 'error' event
^

Error: write EPIPE
at exports._errnoException (util.js:870:11)
at Socket._writeGeneric (net.js:681:26)
at Socket._write (net.js:700:8)
at doWrite (_stream_writable.js:300:12)
at writeOrBuffer (_stream_writable.js:286:5)
at Socket.Writable.write (_stream_writable.js:214:11)
at Socket.write (net.js:626:40)
at Object.module.exports.getCertificateInfo (C:\dev\alexa\node_modules\alexa-verifier\node_modules\openssl-cert-tools\lib\information.js:88:18)
at validateCert (C:\dev\alexa\node_modules\alexa-verifier\index.js:77:18)
at C:\dev\alexa\node_modules\alexa-verifier\index.js:49:18
at Request._callback (C:\dev\alexa\node_modules\alexa-verifier\index.js:67:16)
at Request.self.callback (C:\dev\alexa\node_modules\alexa-verifier\node_modules\request\request.js:200:22)
at emitTwo (events.js:87:13)
at Request.emit (events.js:172:7)
at Request. (C:\dev\alexa\node_modules\alexa-verifier\node_modules\request\request.js:1067:10)
at emitOne (events.js:82:20)
at Request.emit (events.js:169:7)
at IncomingMessage. (C:\dev\alexa\node_modules\alexa-verifier\node_modules\request\request.js:988:12)
at emitNone (events.js:72:20)
at IncomingMessage.emit (events.js:166:7)
at endReadableNT (_stream_readable.js:913:12)

An in-range update of sinon is breaking the build 🚨

Version 4.1.1 of sinon was just published.

Branch	Build failing 🚨
Dependency	sinon
Current Version	4.1.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

---

Commits

The new version differs by 5 commits.

• 3a0e28b Update docs/changelog.md and set new release id in docs/_config.yml
• 989e15b Add release documentation for v4.1.1
• df3adf0 4.1.1
• 0e9bf90 Update History.md and AUTHORS for new release
• 9d9c372 Remove "engines" from package.json

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Timeouts downloading cert from behind proxy

I'm getting timeouts when the module tries to download the certificate from S3. This is due to my corporate proxy. Other than forking and updating the configuration for https, do you have any suggestions?

invalid signature (not base64 encoded)

var verifier = require('alexa-verifier');
console.log(req.headers.signature);
/*
console value of signature
cezVeGIQZ2acr6cmNOC/SoytfBxk35aZluOMAHFImvD2A3EUdXgN/98zxAnbySet6bWLLRY7nb4gSeM8tERBOPSFhlU8q6pN40hHnYP6ELxk2mpCUeyXJmOIGCaVxAVZBohrr7XM/xgrMmWLDZNVTWmSYw0Tkrg0U7EpS/SpkqiulffVpiZE4fO9btpY1D7zBjBYuu/6GYQElc63OcCTuFH1smXK0jCldWdk1SvZ04uyLitxLcpzpRpjZ5Tii34pP1NtMnJLakf9BX26Ko98N4Q8m1j8H06 uaDiDbKNYt48ZX5jnfPh4pO1KyKVaLT0t45ocPQq91pKR9GSxdjAsQ==
*/
console.log(typeof req.headers.signature);
var rawBody = req.body;
//var rawBody = JSON.stringify(req.body);//Had even tried stringifying the body

verifier(req.headers.signaturecertchainurl, req.headers.signature, rawBody, function(passes) {
console.log(passes);
//console gives
//Invalid signature (not base64 encoded)
});

for valid signed requests its responding false.

Hello,

Thank you for the solution, but it's not working for me. it's failing to verify the signature for 2nd, 3rd call from Alexa and passing all other functional tests calls from lambda. But when I run it's separately with the same signature, chainURL and raw body it's working. I can't get around my head into this issue. why it will work separately but not working from the server for 2nd, 3rd call. I know its not an actual issue, but any kind of help will be very much appreciated.

Thank you in advance.

Alexa-App-Server?

Hi,

I tried a variety of ways to get this working with Alexa-App-Server. I suspect its possible to add a file to Alexa-App-Server's 'server/' directory, and tap into 'express.use' (reference login.js example), but all attempts thus far have failed.

Would you kindly share an example of how to leverage alexa-verifier with Alexa-App-Server for each request?

TIA!

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

• engines was only updated if it defined a single version, not a range.
• .nvmrc was updated to Node.js 10
• .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

validate() looks at Common Name value instead of Subject Alternative Names section

In validate-cert.js, this code

// check that the domain echo-api.amazon.com is present in the Subject
// Alternative Names (SANs) section of the signing certificate
if (cert.subject.getField('CN').value.indexOf('echo-api.amazon.com') === -1) {
  return 'subjectAltName Check Failed'
}

checks for the domain in the Common Name field. Shouldn't it be looking in the alt names instead? The alt names are present in cert.extensions[]

verifier always throws error: "invalid signature"

I have an Alexa Skill on the Amazon Dashboard to test, the functionality is hosted on a nodeJS server (with https).

While trying to submit the skill to Amazon, I've received an email that the headers were not validating.

So I was happy to find alexa-verifier and added it to my node app, like so:

var cert_url = req.headers['signaturecertchainurl'];
var signature = req.headers['signature'];
var requestRawBody = JSON.stringify(req.body);
if(cert_url && signature) {
        console.log('-> Cert & Signature exist');
        verifier(cert_url, signature, requestRawBody, function(error) {
            	console.log('-> Verifier - Error? ' + JSON.stringify(error));
                if(!error) {
                    alexaskill(req, resp, next);
                } else {
                    resp.response.status(500);
                    resp.send({"Error": "Error verifying source of request to AlexaAppHandler - " + error});
                    next();
                }
            });
        } else {
            resp.response.status(500);
            resp.send({"error": "Proper headers not found"});
            next();
}

When testing from the Test tab of Alexa's Developer Console, I am always getting at console.log('-> Verifier - Error? ' + JSON.stringify(error)); in the code, this error: -> Verifier - Error? "invalid signature"

I should note, that I do see in the traceout the: cert_url, signature & requestRawBody, and I pass them into the Verifier.

An in-range update of sinon is breaking the build 🚨

Version 4.1.6 of sinon was just published.

Branch	Build failing 🚨
Dependency	sinon
Current Version	4.1.5
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

---

Commits

The new version differs by 10 commits.

• 68c37ed Update docs/changelog.md and set new release id in docs/_config.yml
• cd8ae51 Add release documentation for v4.1.6
• 29e80be 4.1.6
• a5c59a5 Update History.md and AUTHORS for new release
• 0ae60b6 Merge pull request #1653 from mroderick/upgrade-dependencies
• dcd4191 Upgrade browserify to latest
• a316f02 Upgrade markdownlint-cli to latest
• 78ebdb3 Upgrade lint-staged to latest
• fcf967b Upgrade dependency supports-color
• 7c3cb4f Enable StaleBot with default configuration (#1649)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Problem with openssl-cert-tools

Using node 7.4 inside a docker container with openssl available (1.0.2k), I'm getting an error which seems related to openssl-cert-tools, but maybe someone already knows the answer

using alexa-verifier-middleware 0.1.5 which uses alexa-verifier 0.2.0, I'm getting an error within openssl-cert-tools. Here is a simple repro snippet:

let fs = require('fs');
let tools = require('openssl-cert-tools'); // 1.2.1
let request = require('request');
request('https://s3.amazonaws.com/echo.api/echo-api-cert-4.pem', (err, res, body)=>{
	tools.getCertificateInfo(body, function(er, info){});
})

is leading to:

TypeError: Cannot read property 'split' of undefined
    at Socket.<anonymous> (/app/node_modules/openssl-cert-tools/lib/information.js:70:37)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at Socket.Readable.push (_stream_readable.js:134:10)
    at Pipe.onread (net.js:551:20)

Any idea?

Usage of validator module vulnerable version

Issue:

validator package versions before 13.6.0 are vulnerable to ReDOS (Regular Expression Denial of Service) via isEmail and isHSL. The vulnerability can happen when checking if the crafted string is an email.

Suggestion:
Please update validator package to latest version to fix this vulnerability.

add promise support

if invoked without a callback function (e.g., verifier(cert_url, signature, requestBody) return a promise.

verification fails with double-byte utf-8 encodings

the verification will fail anytime the request contains double byte utf-8 encodings.
I believe that all requests from Alexa are UTF-8 encoded.

for example if the request contains the word "déjà vu".. validation will fail.

this seems to fix the issue:

// returns true if the signature for the request body is valid, false otherwise
function isValidSignature(pem_cert, signature, requestBody) {
...
verifier.update(requestBody); // this line can be modified to: verifier.update(requestBody,'utf8');
...
}

Update request header signature to validate against SHA-256

Referencing from here, Amazon as of March 2022 recommends verifying the header's Signature-256 against the SHA-256 hash of the request body, as documented here.

Might also be worth revisiting the checklist to make sure this module is up-to-date for such checks.

An in-range update of nock is breaking the build 🚨

Version 9.1.6 of nock was just published.

Branch	Build failing 🚨
Dependency	nock
Current Version	9.1.5
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

nock is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

---

Release Notes

v9.1.6

9.1.6 (2018-01-08)

Bug Fixes

• implement callback on req.write and req.end. (#1047) (cb20aa1)

Commits

The new version differs by 2 commits.

• 573b42b chore: remove executable bit from interceptor.js. (#1045)
• cb20aa1 fix: implement callback on req.write and req.end. (#1047)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

why rawBody?

@mreinstein This is not issue. But I wanted to know why are you processing rawBody from express.request. What would happen if req.body is sent instead of req.rawBody?

This one mention Signature what is the meaning of this

According to the program we have to pass Signature, What is that mean. From where can I extracted this value. Do I want to generate this. Really confuse this. I have a ssl certificate get from ACM.

validate() doesn't check the "Not Before" date

In validate-cert.js, this code

var notAfter = new Date(cert.validity.notAfter)
var remainingDays = notAfter.getTime() - new Date().getTime()
// check that the signing certificate has not expired (examine both the Not
// Before and Not After dates)
if (remainingDays < 1) {
  return 'certificate expiration check failed'
}

checks the "Not After" date, but it doesn't check the "Not Before" date.

Move into the alexa-js organization?

Would you like to move this repo into the newly created alexa-js organization, https://github.com/alexa-js?

This would reduce bus factor as currently only @mreinstein can add contributors to this project. By moving org admins can at least add new people, currently that's @matt-kruse and myself.

If you do want to do this, because Github requires one be admin of both source and destination, transfer the repo to me (@dblock) and I'll immediately move it to the org.

Getting error invalid signature (not base64 encoded)

My development endpoint is a sub-domain of a domain that has a wildcard certificate from a certificate authority.
the signature i am getting is "cezVeGIQZ2acr6cmNOC/SoytfBxk35aZluOMAHFImvD2A3EUdXgN/98zxAnbySet6bWLLRY7nb4gSeM8tERBOPSFhlU8q6pN40hHnYP6ELxk2mpCUeyXJmOIGCaVxAVZBohrr7XM/xgrMmWLDZNVTWmSYw0Tkrg0U7EpS/SpkqiulffVpiZE4fO9btpY1D7zBjBYuu/6GYQElc63OcCTuFH1smXK0jCldWdk1SvZ04uyLitxLcpzpRpjZ5Tii34pP1NtMnJLakf9BX26Ko98N4Q8m1j8H06 uaDiDbKNYt48ZX5jnfPh4pO1KyKVaLT0t45ocPQq91pKR9GSxdjAsQ==";

More verbose error logging + better error handling

Looking at #16, it would make sense to rewrite some of the error logs to be a bit more verbose. For example, the current message is a bit ambiguous ('certificate verification failed'), whereas the real reason the verification failed is due to a mismatch with signatures ('certificate verification failed due to invalid signature'?). Obviously it's debatable as to what is defined as "verbose enough", but IMHO, it should be just enough to not be too technical and not too vague as well. If needed, a flag can be passed to enable more verbose logging.

Another thing to note is the slight inconsistency with what the individual functions return. For example, validateTimestamp returns a string with the error message. However, validateSignature returns a boolean that is later on used to return an error message to the callback if applicable. A possible change could be something like the following:

// returns true if the signature for the request body is valid, false otherwise
function validateSignature(pem_cert, signature, requestBody) {
  var verifier
  verifier = crypto.createVerify('RSA-SHA1')
  verifier.update(requestBody)
  if (verifier.verify(pem_cert, signature, SIGNATURE_FORMAT)) {
    return null
  } else {
    return 'certificate verification failed due to invalid signature'
  }
}

The last thing I noticed is that if you don't supply a callback parameter, then an empty function is given. Unfortunately, this means that any errors that occur will be discarded and never see the light of day. It might be best to either leave a note in the README about this behavior or have the default callback function print all errors occurred. (callback = function(er) { console.error(er) }?).

Enhance Debugging

Hi Mike,

What are you thoughts about enhancing alexa-verifier to provide more information when alexa-verifier finds that there is a problem with the certificate?

For example, exposing methods such as isValidSignature and perhaps add extra methods for debugging purposes?

Certificate integrity not checked nor is the chain of trust verified

It looks the certificate isn't checked for integrity, nor is the chain verified at all.
Inspecting openssl-cert-tools, it doesn't seem to do any of this.
As a quick test, I tried handing it a counterfeit certificate (I modified the first byte of the signature of the public key, could have modded more, but you get the idea).
The library doesn't detect this, so effectively any self-signed certificate could be handed and will pass, as long as CN starts with echo-api.amazon.com and the certificate hasn't expired yet...

bad-signature.pem.zip

An in-range update of sinon is breaking the build 🚨

Version 4.1.4 of sinon was just published.

Branch	Build failing 🚨
Dependency	sinon
Current Version	4.1.3
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

---

Release Notes

Minor fix for Symbol names and deprecation of spy.reset

• Fix: assertion error messages did not handle Symbol names (#1640)
• Deprecate spy.reset(), use spy.resetHistory() instead (#1446)

Commits

The new version differs by 36 commits.

• 1ea2749 Update docs/changelog.md and set new release id in docs/_config.yml
• 078c082 Add release documentation for v4.1.4
• 571263e 4.1.4
• f2ee9f1 Update History.md and AUTHORS for new release
• a8262dd Assertion error messages handle symbolic method names
• 8fa1e14 Merge pull request #1641 from mroderick/point-to-stack-overflow
• 7c1ebd0 Update issue links to point to sinonjs/sinon
• 93418f6 Update documentation to emphasize Stack Overflow
• ca9e2fa Merge pull request #1636 from fearphage/fix-headless-chrome-in-circle
• 39186f4 use google-chrome-unstable for tests
• 6315621 invalidate cache
• d078af9 try using default chrome install
• 177c4b6 upgraded to the lastest official version of mochify
• ecdc4e0 test with updated mochify
• 360c2e7 added more details and notes

There are 36 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

this module doesn't work on Azure/Windows

I like what you did here, but having some pains in getting it to work in my scenario.
Did you get a Skill approve with this library?

I've been trying to deploy my Skill on Azure as that is our prefered platform.

Getting some issues, as openssl-cert-tools does a spawn('openssl',
And we can't start a process in an Azure Web App

So I replaced openssl-cert-tools with https://github.com/Southern/node-x509 to validate the certificate.
The validation works locally, but node-x509 uses node-gyp, and that comes with it's own pains: http://stackoverflow.com/questions/19039842/node-js-app-with-node-gyp-fails-to-deploy-on-azure-website

At this point, I'm going to try the Docker on a linux VM deployment option, but I'm getting close to going the Lambda passthrough way like most people seem to do.