Jira (PUP-3446) CertificateError when running tests with OpenSSL >= 1.0.1i
Title: Message Title Anchor created an issue Puppet / PUP-3446 CertificateError when running tests with OpenSSL >= 1.0.1i Issue Type: Bug Affects Versions: PUP 3.7.1, PUP 3.7.0, PUP 3.6.2, PUP 3.6.1, PUP 3.6.0, PUP 3.5.1, PUP 3.5.0 Assignee: Eric Sorenson Components: Test Infrastructure Created: 12/Oct/14 8:31 PM Environment: Debian sid (workstation used for testing) rbenv with Rubies 2.0.0-p353, 1.9.3-p194, 1.8.7-p352 and 1.8.7-p302 Priority: Minor Reporter: Anchor The :minimal_certificate stub in Puppet::Network::HTTP::RackREST does everything necessary to produce a valid test certificate except sign it. An unsigned certificate has empty signing algorithm fields, which is invalid ASN.1, although OpenSSL versions prior to 1.0.1i would accept this ASN.1 anyway. When these tests are run on OpenSSL 1.0.1i or newer, an OpenSSL::X509::CertificateError is raised with the message "nested asn1 error". I have confirmed that the resultant ASN.1 is invalid using the dumpasn1 utility, ruling out a bug in OpenSSL reading the certificate. To reproduce the problem, simply ru
Jira (PUP-3446) CertificateError when running tests with OpenSSL >= 1.0.1i
Title: Message Title Anchor commented on an issue Re: CertificateError when running tests with OpenSSL >= 1.0.1i https://github.com/puppetlabs/puppet/pull/3183 Add Comment Puppet / PUP-3446 CertificateError when running tests with OpenSSL >= 1.0.1i The :minimal_certificate stub in Puppet::Network::HTTP::RackREST does everything necessary to produce a valid test certificate except sign it. An unsigned certificate has empty signing algorithm fields, which is invalid ASN.1, although OpenSSL versions prior to 1.0.1i would accept this ASN.1 anyway. When these tests are run on OpenSSL 1.0.1i or newer, ... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-3470) Syntax error in test suite on Ruby <= 1.8.7-p352
Title: Message Title
Anchor created an issue
Puppet / PUP-3470
Syntax error in test suite on Ruby <= 1.8.7-p352
Issue Type:
Bug
Assignee:
Eric Sorenson
Components:
Test Infrastructure, Trivial
Created:
14/Oct/14 7:24 PM
Environment:
Debian sid (workstation used for testing) rbenv with Rubies 2.0.0-p353, 1.9.3-p194, 1.8.7-p352 and 1.8.7-p302
Priority:
Minor
Reporter:
Anchor
https://github.com/puppetlabs/puppet/commit/baee7126eca089adc894e8ae7232fc3eb698f0c7 introduced a syntax error in the test suite on older Ruby 1.8.7 versions. I've confirmed failure on 1.8.7-p352 and 1.8.7-p302, although it seems to have passed on 1.8.7-p374 on Travis.
The problem is that older Rubies don't know that this is a single logical line of code, and need the newline to be escaped:
expect(PSON.parse(text)) .to eq({"data" => {}, "document_type" => "Node"})
I'm not sure whether this is worth filing a ticket for, but CONTRIBUTING.md requests that commit messages reference a bug number, which is why I'm putting this into Jira. I'll be submitting a trivial pull request shortly.
Jira (PUP-3470) Syntax error in test suite on Ruby <= 1.8.7-p352
Title: Message Title Anchor commented on an issue Re: Syntax error in test suite on Ruby <= 1.8.7-p352 https://github.com/puppetlabs/puppet/pull/3196 Add Comment Puppet / PUP-3470 Syntax error in test suite on Ruby <= 1.8.7-p352 https://github.com/puppetlabs/puppet/commit/baee7126eca089adc894e8ae7232fc3eb698f0c7 introduced a syntax error in the test suite on older Ruby 1.8.7 versions. I've confirmed failure on 1.8.7-p352 and 1.8.7-p302, although it seems to have passed on 1.8.7-p374 on Travis. The problem is that older Rubies don't know that this is a single logical line of co... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-3446) CertificateError when running tests with OpenSSL >= 1.0.1i
Title: Message Title Anchor commented on an issue Re: CertificateError when running tests with OpenSSL >= 1.0.1i https://github.com/puppetlabs/puppet/pull/3183 has been closed in favour of https://github.com/puppetlabs/puppet/pull/3150, since they both solve the same issue. (I did check the bug tracker before creating this issue, but not existing pull requests.) Add Comment Puppet / PUP-3446 CertificateError when running tests with OpenSSL >= 1.0.1i The :minimal_certificate stub in Puppet::Network::HTTP::RackREST does everything necessary to produce a valid test certificate except sign it. An unsigned certificate has empty signing algorithm fields, which is invalid ASN.1, although OpenSSL versions prior to 1.0.1i would accept this ASN.1 anyway. When these tests are run on OpenSSL 1.0.1i or newer, ... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit thi
Jira (PUP-2310) Puppet client does not update and does consult the crl during authentication
Title: Message Title
Anchor commented on an issue
Re: Puppet client does not update and does consult the crl during authentication
I've submitted https://github.com/puppetlabs/puppet/pull/3247, which is a fix for https://projects.puppetlabs.com/issues/16842 (which was marked as a duplicate of this issue).
That pull request defines CertificateRevocationList#expiration to return the CRL's next_update timestamp, so that the indirector cache knows to invalidate it once next_update is passed. It does not address the broader issue of when the CRL should be consulted, nor does it fix the reported problem with the agent not fetching a missing CRL (I haven't tried to reproduce the latter problem).
Add Comment
Puppet / PUP-2310
Puppet client does not update and does consult the crl during authentication
I my tests puppet client never updates it's /var/lib/puppet/ssl/ca/ca_crl.pem from the master even if I delete it - it is not fetched from master then client runs. Another issue is that puppet client does not consult the crl - after revoking cert of node dev2.internal on master - and manually copying /var/lib/puppet/ssl/ca/{ca_crl.pem,inventory.txt} t...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-3589) 'ensure' parameter is always treated as if it were a property
Title: Message Title Anchor created an issue Puppet / PUP-3589 'ensure' parameter is always treated as if it were a property Issue Type: Bug Affects Versions: PUP 3.7.2, PUP 2.7.23 Assignee: Unassigned Created: 30/Oct/14 1:06 AM Priority: Minor Reporter: Anchor Puppet (since at least 2.6.0; I've marked the earliest and latest available released versions as affected) considers any parameter named 'ensure' on a type to be a property that can be synced. While this is true for all built-in types, it is not generally true. A property is a special type of parameter, and if 'ensure' is not a property, then Ruby will throw undefined method exceptions in at least two different places in the code because Puppet assumes that methods defined by Puppet::Property are available. A real-world use case where it makes sense to have an 'ensure' parameter which is not a property is a type that exists only to generate additional resources on the agent. For example, we have a custom type (Gen_file) that has a 'command' parameter, runs this command on the agent, and generates a File resource with the command output as its contents. Gen_file itself has no syncable state, so it makes no sense for it to have properties, but it does have an 'ensure' parameter whose value is passed onto the generated File resource's 'ensure' property. I intend to submit a pull request to fix this behaviour shortly, which will highlight the specific parts of the code where this assumption is made.
