Any guess yet on when this might be released? Thanks, Debbie

On Oct 26, 2016, at 9:43 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:

Thanks for preparing those patches. I installed them in the development repository along with the attached, which uses a fakauʻa in Pulu ʻAnau's name (I assume this is the proper orthography for a Tongan name - please correct me if wrong), and which replaces the invented time zone abbreviations with numeric ones.

It looks like we'll need a new release soon, since the current data are wrong starting about ten days from now. This is not enough notice of course. <tonga.txt>

Any updated guesses? Testing is not a problem. Thanks, Debbie

On Oct 28, 2016, at 2:30 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:

On 10/28/2016 02:02 PM, Deborah Goldsmith wrote:

...

Any guess yet on when this might be released?

It should be fairly soon, although there is no specific schedule. You should be able to test with what's in the development repository now.

Hi, On 11/02/2016 05:57 PM, Deborah Goldsmith wrote:

Given that this was first brought up on October 26 and it’s now November 3 in Tonga, when is this going to be released?

Yes, I know it’s checked into the informal GitHub repository. That doesn’t work for everyone.

Rather soon / now: https://github.com/eggert/tz/commit/9774c293b7ea6ec7be851cb0b2a0807840e6793e Andreas -- Andreas Stieger <astieger@suse.com> Project Manager Security SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

On Nov 3, 2016, at 6:08 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:

On 11/02/2016 09:57 AM, Deborah Goldsmith wrote:

...

I know it’s checked into the informal GitHub repository. That doesn’t work for everyone.

Now that we have an official release with the Tonga changes, your developers should be OK to run with it.

Why doesn't the GitHub development repository work for them? Are there technical problems with using Git or GitHib? Or is this more a case of not using the data until it's "blessed" somehow? Either way, there should be some way to address the problem other than by having your folks wait impatiently for tarballs to show up at iana.org.

There needs to be an official source that has acceptable latency and reliability. It has to be documented as being that official source. It's ok to have unofficial sources but they aren't official sources, as the term indicates. It's also possible to have several official sources, for fault tolerance or improved latency. If that is done, they have to match (give or take latency for the most recent update) and there must be a straightforward and reliable way to recognize a new change. If you want to give up on IANA and make Github the official source, that's certainly an option. If you want to keep IANA as the sole official source, that's another option. But if you call X the official source, you should not be surprised when people are hesitant to use unofficial source Y rather than official source X. paul

On Nov 4, 2016, at 1:19 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 11/04/2016 07:28 AM, Paul.Koning@dell.com wrote:

...

if you call X the official source

I try not to do that for any X. The tz project has succeeded in part because it is not run by the UN or by any other official agency. The 'Theory' file says "The tz database is not authoritative", and I try to keep politics out of the data, so that we avoid the sort of bureaucacy that being "official" would entail.

That makes good sense. I didn't mean "official" in the sense of "sanctioned by some internationalbureaucrat body" but rather in the sense of "released by the TZ project as a formal release rather than an interim work product".

...

If you want to give up on IANA and make Github the official source, that's certainly an option. In practice, tagged revisions on GitHub are just as "official" as tarballs on IANA. This doesn't at all mean that I've given up on IANA; it's just how things work now.

Ok. If that's the intent, it would be good for the Theory file to say so. paul

I think Paul meant that the "official" release would be the act of tagging the repo with the new version, not any random change. On November 4, 2016 1:43:26 PM EDT, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> wrote:

On 2016-11-03 16:08, Paul Eggert wrote:

...

On 11/02/2016 09:57 AM, Deborah Goldsmith wrote:

...

I know it’s checked into the informal GitHub repository. That doesn’t work for everyone. Now that we have an official release with the Tonga changes, your developers should be OK to run with it. Why doesn't the GitHub development repository work for them? Are there technical problems with using Git or GitHib? Or is this more a case of not using the data until it's "blessed" somehow? Either way, there should be some way to address the problem other than by having your folks wait impatiently for tarballs to show up at iana.org.

With processes checking if a new release has been packaged or announced and sources have been updated and tagged, kicking off the download, build, test, package, release, announce cycle, you need a reliable flag or flags to kick off the process, which could be one, more, or all of the above checks. Triggering on just any change in the remote GitHub repo, which does see a fair amount of churn many months, may not be acceptable, where it may be with projects in local repos using Continuous Integration processes.

Changing one of these production processes in any org is not likely to be a lightweight undertaking, and involve spending budget on process changedevelopment and testing, where it may be considered better spent on more pressing significant current problems.

Personally, a cron job checks daily if IANA ...latest symlinks contain a version differing from the last download, then downloads, archives, diffs, builds, compares, installs, and emails a file:// link to the log, to let me know something (attempted to be) changed.

-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

One thing I notice about the github release tags is that they don't include the signature on the tarball. If the tarballs can be reproducibly created on the github repository, I imagine it would go a long way to say that the "official" distribution is the one that has been signed. Assuming that the key it's signed with is trusted, then any number of mirrors could be considered "official" sources, since it is trivial to verify that the data has not been changed. If people feel comfortable treating the IANA as the trusted agency for distribution, they could host the (static, unchanging) public key somewhere. There is a way to sign tags directly, but I'm not sure that there's a way to actually verify the signature without cloning the git repository. It might be worth looking into some sort of script or hook that automatically generates signed tarballs for distribution when the repository is tagged. On November 4, 2016 2:31:42 PM EDT, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 11/04/2016 11:06 AM, Paul G wrote:

...

I think Paul meant that the "official" release would be the act of tagging the repo with the new version, not any random change.

Yes, that's the intent. I installed the attached proposed patch to try to clarify this. Most of the changes are to tz-link.htm not Theory, since tz-link.htm talks about the distribution procedure.

Paul G <paul@ganssle.io> writes:

There is a way to sign tags directly, but I'm not sure that there's a way to actually verify the signature without cloning the git repository. It might be worth looking into some sort of script or hook that automatically generates signed tarballs for distribution when the repository is tagged.

GitHub will verify the signatures on tags for you if you upload the PGP public key used to sign the tags to GitHub, and show the signature as verified in their UI. (Of course, that assumes you trust GitHub to do that verification.) -- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>

Andreas Heigl <andreas@heigl.org> writes:

Am 04.11.16 um 20:15 schrieb Russ Allbery:

...

GitHub will verify the signatures on tags for you if you upload the PGP public key used to sign the tags to GitHub, and show the signature as verified in their UI. (Of course, that assumes you trust GitHub to do that verification.)

It's a feature from git itself, not github. https://git-scm.com/book/uz/v2/Git-Tools-Signing-Your-Work

It is based on GPG-Keys so there's no central trusted instance which can be a benefit or a curse depending on how you look at it.

You and I are talking about different things. I'm talking about the green "Verified" text on, for example: https://github.com/rra/remctl/tags -- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>

Andreas Heigl <andreas@heigl.org> writes:

Am 04.11.16 um 20:37 schrieb Russ Allbery:

...

Andreas Heigl <andreas@heigl.org> writes:

...

Am 04.11.16 um 20:15 schrieb Russ Allbery:

...

...

...

GitHub will verify the signatures on tags for you if you upload the PGP public key used to sign the tags to GitHub, and show the signature as verified in their UI. (Of course, that assumes you trust GitHub to do that verification.)

...

...

It's a feature from git itself, not github. https://git-scm.com/book/uz/v2/Git-Tools-Signing-Your-Work

...

...

It is based on GPG-Keys so there's no central trusted instance which can be a benefit or a curse depending on how you look at it.

...

You and I are talking about different things. I'm talking about the green "Verified" text on, for example:

...

https://github.com/rra/remctl/tags

we are actually talking abuot the same thing. The tag is signed with your private key. As soon as you upload your public key to github, they can verify the signed tag and add the "Verified" Text. And everyone else can verify the tag also as long as they have your public key.

BTW: Since git 1.7.5 (I think) you can also sign commits and GitHub will mark them as verified.

Ah, okay, then we're just talking past each other. Yes, the tag signing (and commit signing in general) is built into Git and you can have Git do the verification. All I had meant to point out is that GitHub will also do that verification and present the results in the UI, which may be useful for less sophisticated users who don't want to configure Git and who want to just download a tarball from GitHub, but want some guarantee that this was a signed release. -- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>

On 11/04/2016 12:03 PM, Paul G wrote:

One thing I notice about the github release tags is that they don't include the signature on the tarball. If the tarballs can be reproducibly created on the github repository, I imagine it would go a long way to say that the "official" distribution is the one that has been signed.

The tarballs are reproducible, albeit with developer tools (e.g., one needs a 'tar' that is compatible with GNU Tar). I could email signatures (.asc files) to tz@iana.org as soon as soon as I generate the them, and this would let hurried but paranoid developers retrieve tagged commits and generate and verify the tarballs themselves, as long as they have the proper tools. This all sounds complicated, though. The developers of Oracle's TZUpdater tool apparently found the .asc files to be too much of a hassle, and instead use SHA-512 checksums from a central server instead. Should we slap more gingerbread atop a signature-checking procedure that already may be a bridge too far?

On 2016-11-04 13:51, Paul.Koning@dell.com wrote:

...

On Nov 4, 2016, at 3:27 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote: This all sounds complicated, though. The developers of Oracle's TZUpdater tool apparently found the .asc files to be too much of a hassle, and instead use SHA-512 checksums from a central server instead. Should we slap more gingerbread atop a signature-checking procedure that already may be a bridge too far? No. If people don't know how to handle .ASC files, let them learn. That's elementary IT technology; it's not our job to work around people who haven't learned the tools of their trade.

Think you may be jumping to unjustified conclusions, based on totally incorrect assumptions. More likely Oracle is just cognizant of their customers, who each may have hundreds or thousands of heavily firewalled back end servers, whose security staff don't want to punch a hole through to the internet, or add other products of limited utility that have to be security qualified before they can be installed on servers, and whose every patched release has to be requalified. Their "updated" approach is probably their standard method for corporate customers. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> writes:

I know he does, but this is not documented anywhere, and he changed where the version is found, and that is not documented anywhere, whereas the IANA process is documented in an RFC.

Companies are unlikely to change their processes unless changes break existing processes (like the version change) or changes are documented in an RFC, which can be presented to SOx auditors and their ilk, to document and justify why they spent money and changed a process, along with the documentation on change impact including budget, authorizations, and the dozens of other side efforts of production changes, summarized above by DG as "That doesn’t work for everyone."

A bit of a digression, but the way companies treat free software projects and maintainers is a pet peeve of mine. It should be obvious that the only people a company can expect to follow any of those rules are people the company is paying or otherwise has a contractual relationship with that requires following those rules. Otherwise, the company should be prepared to pay one of their employees to jump through those hoops if they want those hoops jumped through. It's standard practice for companies who depend heavily on a free software project to have an internal maintainer or advocate for that free software project who will translate whatever the public maintainer does into the form that the company needs to manage it internally, including maintaining private branches as needed, pulling up unreleased patches as needed, and adjusting for upstream changes that don't match the needs of the company (or clearly advocating for compromises or modifications that work for the entire community). This is a cost of doing business. My employer certainly does this for free software we use. It's fairly normal. Some companies don't *want* to spend that money, and try to do it on the cheap by not having that person or the mechanisms for importing free software properly. A few of them then complain at the free software maintainer when they run into problems. But those complaints should not carry any more weight than the complaints of any other user, and should be weighed against the work style, goals, and available time of the free software maintainer. After all, the actor in this situation that has (by far) the most resources and hence the most ability to adopt to changes, whether they want to or not, is the company, not the free software maintainer. -- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>