akkornel / config-apple-profile Goto Github PK

In the Wi-Fi payload, the DisplayedOperatorName payload key is missing a description.

This is an upstream bug, because the Config. Profile Reference doesn't provide a description. Radar #18497983 has been opened for this.

Some payloads have Date or Float types, for which support needs to be added.

A test suite is missing for the contents of the Payload base class!

We do not try to validate PKCS#12 certificates yet.

In the EAPClientConfiguration class, we should be able to validate inserted values for the AcceptEAPTypes and TLSTrustedServerNames keys, which are both arrays.

Compilations are falling on systems that do not have OpenSSL installed, or at least do not have it installed in any of the locations we are checking.

Example report: http://www.cpantesters.org/cpan/report/4adc8ea6-4ffa-11e4-80ff-b19aba752602

The Certificate payloads are missing their test suite!

CPAN tests are failing in test suite 11-number.t on 32-bit systems. All of the failed tests appear to be involving the two big numbers in the list of known-good numbers. Interestingly, the tests fail even though the test suite says that the Perl is using 64-bit numbers.

One such report is available at http://www.cpantesters.org/cpan/report/a93e15ee-60f5-11e4-9dc2-bfba930e45bb

Right now, the UUID test suite doesn't test the handling of Data::UUID objects, or of Base64-encoded strings. This needs to be done.

The ServiceProviderRoamingEnabled payload key is missing a default value. This doesn't affect the payload key definition, just the documentation.

Issue #18579735 has been opened on the Apple Bug Reporter site.

We now have several instances of payloads including keys which are "arrays of" or "dicts of" something. Our test scripts are checking the type (array or dict), but not the subtype, and they need to.

During my testing, I found that iOS is not accepting identity certificates that do not have the password embedded in the payload. iOS prompts the user for the password, but then says the password is wrong, asking the user to try again.

Mac OS X has no problem with the same profile.

The Data type is missing its test suite!

With Firefox's removal of trust of 1024-bit RSA keys, it's becoming more likely that Apple will do the same thing in the future. A note should be added to the Certificate payload POD.

We need to make sure things fail properly if the filehandle is not readable.

I have to find something that can not seek!