TestMain::test_loadfile gets stuck in 2038

[bmwiedemann]

While working on reproducible builds for openSUSE, I found that running the python-snimpy tests after 2038-01-19 lets them get stuck.

Specifically tests/test_main.py::TestMain::test_loadfile (might only be the first one to trigger).

to reproduce on Debian or openSUSE, I use

osc co openSUSE:Factory/python-snimpy && cd $_
osc build --clean --noservice --vm-type=kvm --build-opt=--vm-custom-opt="-rtc base=2038-01-19T08:00:00"

The date indicates that somewhere seconds since 1970-01-01 are stored in a signed 32-bit int that overflows after 0x7fffffff

Background: As part of my work on reproducible builds for openSUSE, I check that software still gives identical build results in the future. The usual offset is +16 years, because that is how long I expect some software will be used in some places. This showed up the stuck test in our package build.

[vincentbernat]

This is stuck because PySNMP cannot spawn an agent for testing due to the fact it tries to instantiate an snmpEngineTime which is a signed 32-bit integer. If people are still using SNMP in 2038, maybe they should cope with the consequences. :)

[bmwiedemann]

looking at pysnmp/smi/mibs/SNMP-FRAMEWORK-MIB.py:

snmpEngineTime = MibScalar((1, 3, 6, 1, 6, 3, 10, 2, 1, 3), SnmpEngineTime().subtype(subtypeSpec=ValueRangeConstraint(0, 2147483647))).setUnits('seconds').setMaxAccess("readonly")

It seems to be an unsigned 31-bit integer atm, so why not change it into an unsigned 32-bit int to give people another 78 years to migrate?

[vincentbernat]

This is part of RFC 3411. But in fact, this is just a counter, so it could be wrapped.

[bmwiedemann]

    DESCRIPTION "The number of seconds since the value of
                 the snmpEngineBoots object last changed.

sounds as if it should be lower anyway.