fitsverify is broken with new cfitsio v3.430

[jehturner]

I see that a new cfitsio build was put in the AstroConda channel on Friday. This appears to have broken the existing fitsverify package (reported by Ken), which probably requires a corresponding update of its own:

> fitsverify
fitsverify: error while loading shared libraries: libcfitsio.so.2: cannot open shared object file: No such file or directory

The new cfitsio package provides libcfitsio.so.5, rather than the libcfitsio.so.2 that the fitsverify binary is looking for. Thanks!

[jehturner]

PS. I'm not sure what other packages might be similarly affected. I think this also affects aXe, @sosey.

[sosey]

cfitsio was released to fix a security flaw:

CFITSIO Version 3.43 released with security vulnerability fixes along with other bug fixes and enhancements. We highly recommend upgrading to this version. (see https://heasarc.gsfc.nasa.gov/FTP/software/fitsio/c/docs/changes2.txt).

[jehturner]

Right, I think I may have seen that. Note that some IRAF packages have their own cfitsio bundled (I suspect it's strictly not safe to run IRAF on a Web server anyway). Have you tried building aXe against this version?

[sosey]

True. Do we know which packages require their own pinned version of cfitsio and is it possible to point them to a general one for all of IRAF? or will that risk breaking too much more?

[jehturner]

I'm not sure about astroconda-contrib, but from a cursory check, I believe iraf itself (2 copies), iraf.axe, iraf.cirred & iraf.fitsutil. There also seems to be a copy in iraf.tables that I cut out of the build because it was already being linked against the copy already in IRAF (or something).

[sosey]

🙄 blarg.

[jehturner]

Yes, I wouldn't be terribly optimistic about simply replacing those without breakage. You never know though.

[rendinam]

Packages in the Astroconda channel that depend upon cfitsio, namely crds and fitsverify, have been rebuilt so that they now link against the correct cfitsio libname.

[jehturner]

Thanks.

Yes, I should have clarified that I think all the IRAF packages except iraf.axe are linked statically. So it's just that IRAF may not be secure, which probably won't surprise anyone.

[jehturner]

Fitsverify LGTM, but I think it should depend on cfitsio >=3.430, rather than just cfitsio? When I did a conda update fitsverify (as a deliberate check), I initially got the new fitsverify without the cfitsio update, causing a similar error:

fitsverify: error while loading shared libraries: libcfitsio.so.5: cannot open shared object file: No such file or directory

[rendinam]

Good catch. Thanks! The recipes have been updated accordingly, and the packages rebuilt.

[jehturner]

Well, I suppose this is back to me now. I have put "rebuild iraf.axe" on my to-do list yet again! Maybe I can do that tomorrow.

[sosey]

<KHAAAAANNNNNN!!!!!>

[jehturner]

OK, there are some new aXe builds at http://astroconda.gemini.edu/public, if you'd like to give them a quick test, @sosey (I have just checked that they install & find their dependencies).

Regarding the rest of IRAF, everyone, I'm going to propose that we consider not doing anything about it, on the grounds of limited effort and because I have no confidence that IRAF would be able to process untrusted input securely on a server even if we were to replace its ancient copies of cfitsio (which might not be a trivial change). We could keep an eye out for any upstream developments though. I see there is a post from Ole at http://iraf.net/forum/viewtopic.php?showtopic=1469823 (which I might ask him about). What do you think?

@rendinam, @jhunkeler: thanks for the fitsverify fix. What do you think about adding a FAQ entry along these lines?

Can I run AstroConda on a Web server?
We do not independently audit our upstream packages for security [as far as I know]. AstroConda includes some older software, such as IRAF, that was probably not designed with modern security considerations in mind and may be unsuitable for deployment as part of a service that accepts untrusted input. Before offering services based on AstroConda to third parties, users should therefore satisfy themselves as to the security of the packages concerned.