Project

General

Profile

Bug #4771

edrget http test not working

Added by John Bonn about 1 year ago. Updated 8 months ago.

Status:
Closed
Priority:
High
Category:
Applications
Target version:
Impact:

Test will work. edrget will continue to run as usual.

Software Version:
Test Reviewer:

Description

edrget http test not working
switching to http from https fixes problem.

This is breaking nightly tests.

History

#1 Updated by Tammy Becker about 1 year ago

  • Status changed from New to Acknowledged

#2 Updated by Stuart Sides about 1 year ago

  • Category changed from Infrastructure to Applications
  • Status changed from Acknowledged to Assigned
  • Assignee set to Christopher Combs
  • Target version set to 3.5.1 (Sprint 1)

#3 Updated by Christopher Combs about 1 year ago

  • Status changed from Assigned to In Progress

#4 Updated by Christopher Combs about 1 year ago

  • Impact updated (diff)

#5 Updated by Christopher Combs about 1 year ago

  • Status changed from In Progress to Resolved

#6 Updated by John Bonn about 1 year ago

  • Status changed from Resolved to Closed

Looks fine - commit ASAP so it's in next nightly build.

#7 Updated by John Bonn 11 months ago

  • Status changed from Closed to Rejected

This is still failing as of 5/26/2017

#8 Updated by Christopher Combs 11 months ago

  • Status changed from Rejected to In Progress

#9 Updated by Tyler Wilson 10 months ago

Installing the DOIRootCA2.cer file on all of our development machines fixed this problem except for
the systems running OS X. The edrget application was still failing on the http test when attempting to execute this command:

edrget URL=https://pds-imaging.jpl.nasa.gov//data/mro/mars_reconnaissance_orbiter/marci/mrom_0209/calib/vis1flat.ddd

dtruss output comparing the system calls made when running curl to download this file compared to edrget revealed that edrget was not looking in the correct place for the keychain. This is where it should be
looking: /System/Library/Keychains/SystemRootCertificates.keychain

It is possible to manually add the certificate to the keychain Qt returns, and this will remove the error:

bool ResourceGet::getResource(const QUrl &url, QString topath, int timeout) {
    //tjw:
    m_timeOut = timeout;

    // Need to setup output file 
    QString localFileName;
    if (topath.size() != 0) {
      localFileName += topath;
      localFileName += "/";
    }

    // The local file is named according to the external resource name
    // i.e. if there is no filename in the URL, we can't name our local file to write to
    localFileName +=  QFileInfo(url.path()).fileName();
    if (localFileName.isEmpty() ) {
      QString msg = QString("URL has no filename, can't create local output file");
      m_progress.SetText(msg);
      if (!m_isInteractive)
         cout << msg.toStdString() << endl;

      m_error = true;
      return m_error;
    }

    // Handle any problems with opening the local output file
    m_file.setFileName(localFileName);
    if (!m_file.open(QIODevice::WriteOnly) ) {
      QString msg = QString("Cannot open output file: ");
      msg += m_file.error();
      m_progress.SetText(msg);

      if (!m_isInteractive)
         cout << msg.toStdString() << endl;

      m_error =  true;
      return m_error;
    }

    // Establish the connection and start the GET request

    QSslConfiguration config = QSslConfiguration::defaultConfiguration();

    QList<QSslCertificate> caCerts= config.caCertificates();

    QList<QSslCertificate> doirootca2= QSslCertificate::fromPath(QLatin1String("DOIRootCA2.cer"));

    caCerts.push_front(doirootca2.first());


    for (int i=0;i < caCerts.count();i++) {

      qDebug() << caCerts[i].serialNumber();

    }


    config.setCaCertificates(caCerts);
    QSslConfiguration::setDefaultConfiguration(config);
    m_networkMgr.connectToHost(url.host(),url.port());


    // We obtain ownership of the QNetworkReply *, so need to delete later

    m_reply = m_networkMgr.get(QNetworkRequest(url));



    connect(m_reply, SIGNAL(finished()),
            this, SLOT(connectionFinished()));
    connect(m_reply, SIGNAL(readyRead()),
            this, SLOT(downloadReadyRead()));
    connect(m_reply, SIGNAL(downloadProgress(qint64, qint64)),
            this, SLOT(updateDownloadProgress(qint64, qint64)));

    m_lastDone = -1;
    m_error = false;
    return m_error;
  }

However, the certificate could change at any time, and then the problem would reappear.

This appears to be a problem with Qt, and as a temporary fix the following patch was applied
to the ResourceGet::getResource function:

// We obtain ownership of the QNetworkReply *, so need to delete later

    m_reply = m_networkMgr.get(QNetworkRequest(url));

    QString productType(QSysInfo::productType());
    productType = productType.toLower();

    //If this is running on OS X, then this if statement gets around the SSL Handshaking
    //errors because Qt is not looking for the DOI root certificate in the correct
    //place.  Probably here:  /System/Library/Keychains/SystemRootCertificates.keychain
    //which is where curl looks when downloading this file.

    if (productType.contains("osx") ) {
       m_reply->ignoreSslErrors();
    }


==Tyler Wilson (tjwilson@usgs.gov)

#10 Updated by John Shinaman 10 months ago

  • Status changed from In Progress to Testing

#11 Updated by John Shinaman 10 months ago

  • Test Reviewer set to John Shinaman

Tested and operating as advertised.

#12 Updated by Stuart Sides 8 months ago

  • Target version changed from 3.5.1 (Sprint 1) to 3.5.2 (2017-01-31 Jan)

#13 Updated by Christopher Combs 8 months ago

  • Status changed from Testing to Closed

Also available in: Atom PDF