Topics

FW: [ARRL-LoTW] TQSL 2.5 Release now available

Dave AA6YQ
 

There are several improvements in this new version of TQSL that DXLab users will find useful; installation URLs are provided in Rick K1MU's message, appended below.

------------------------

When installing a Callsign Certificate, don't display errors about expired root certificates.

When listing DXCC entities, move the Deleted entities to the end of the list. This helps with the confusion between "Germany (DELETED)" and "FEDERAL REPUBLIC OF GERMANY", especially for persons where English is not a primary language. Allow the "DELETED" string in those names to be translated.

Eliminate the use of the term "duplicates" when referring to already uploaded QSOs as that term means something else in normal usage.

When editing a Station Location, do not force default values for station information fields. Only provide default values when a new station location is being created.

Fix incorrect ADIF output for several modes when creating files using the ADIF editor built into TQSL.

Use ARRL web service to validate US callsigns and pre-fill address info.

Fix TQSL updates failing on Windows when the user's home directory has non-ASCII characters.

Detect running TQSL "As Administrator" and warn the user. Allow this warning to be permanently overridden.

Verify that the TQSL working directory is writable during startup.

Disable prompting for callsign certificate password by default. Add a preference setting to allow this to be re-enabled if desired.

Fix error that was not overriding station location details with the default values when editing an existing station location.

Fix OSX error where the "Edit Station Location" icon was getting squashed.

Update "Waiting for Callsign Certificate" icon to a clock versus the slashed circle. The latter was being interpreted as something broken versus something to wait for.

Keep track of Callsign Certificate requests and reject attempts to request certificates for the same callsign more than 3 times in 24 hours. This limit will hopefully stop people from mistakenly re-requesting callsign certificates repeatedly for the same call because they don't realize that action needs to be taken by ARRL staff to complete the process.

Correct defect that could cause TQSL to crash upon exit while attempting to back up.

When requesting US 1x1 callsigns, which always require signing, don't ask for a certificate type for the request. Require that the user have a valid certificate for some other call to proceed. Remove the "1x1" callsign option from the certificate request type page.

When creating callsign certificates, ask for the type of certificate first as that then drives the next set of questions to ask.

Kudos to Rick K1MU!

73,

Dave, AA6YQ

-----Original Message-----
From: ARRL-LoTW@... [mailto:ARRL-LoTW@...] On Behalf Of Rick Murphy
Sent: Sunday, November 10, 2019 10:00 AM
To: ARRL-LoTW@...
Subject: [ARRL-LoTW] TQSL 2.5 Release now available

The final release of TrustedQSL is now available. Once ARRL HQ staff pick up these images they'll be signed and published on the ARRL website. Windows users will be offered the update when it is published.

Release notes attached.

If you wish to get these immediately, they're published at the following links:

https://www.rickmurphy.net/lotw/tqsl-2.5.msi - Windows

https://www.rickmurphy.net/lotw/tqsl-2.5.dmg - 64-bit Mac

https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.dmg - 32 bit/PPC Mac

https://www.rickmurphy.net/lotw/tqsl-2.5.tar.gz - Linux, BSD, etc.

Thanks to everyone who helped with testing this version.

73,

-Rick
--
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Stan Gammons
 

2.4.7 is all I see when I check for updates.  Am I missing something?


73

Stan
KM4HQE

On 11/10/19 11:50 AM, Dave AA6YQ wrote:
There are several improvements in this new version of TQSL that DXLab users will find useful; installation URLs are provided in Rick K1MU's message, appended below.

------------------------

When installing a Callsign Certificate, don't display errors about expired root certificates.

When listing DXCC entities, move the Deleted entities to the end of the list. This helps with the confusion between "Germany (DELETED)" and "FEDERAL REPUBLIC OF GERMANY", especially for persons where English is not a primary language. Allow the "DELETED" string in those names to be translated.

Eliminate the use of the term "duplicates" when referring to already uploaded QSOs as that term means something else in normal usage.

When editing a Station Location, do not force default values for station information fields. Only provide default values when a new station location is being created.

Fix incorrect ADIF output for several modes when creating files using the ADIF editor built into TQSL.

Use ARRL web service to validate US callsigns and pre-fill address info.

Fix TQSL updates failing on Windows when the user's home directory has non-ASCII characters.

Detect running TQSL "As Administrator" and warn the user. Allow this warning to be permanently overridden.

Verify that the TQSL working directory is writable during startup.

Disable prompting for callsign certificate password by default. Add a preference setting to allow this to be re-enabled if desired.

Fix error that was not overriding station location details with the default values when editing an existing station location.

Fix OSX error where the "Edit Station Location" icon was getting squashed.

Update "Waiting for Callsign Certificate" icon to a clock versus the slashed circle. The latter was being interpreted as something broken versus something to wait for.

Keep track of Callsign Certificate requests and reject attempts to request certificates for the same callsign more than 3 times in 24 hours. This limit will hopefully stop people from mistakenly re-requesting callsign certificates repeatedly for the same call because they don't realize that action needs to be taken by ARRL staff to complete the process.

Correct defect that could cause TQSL to crash upon exit while attempting to back up.

When requesting US 1x1 callsigns, which always require signing, don't ask for a certificate type for the request. Require that the user have a valid certificate for some other call to proceed. Remove the "1x1" callsign option from the certificate request type page.

When creating callsign certificates, ask for the type of certificate first as that then drives the next set of questions to ask.

Kudos to Rick K1MU!

73,

Dave, AA6YQ

-----Original Message-----
From: ARRL-LoTW@... [mailto:ARRL-LoTW@...] On Behalf Of Rick Murphy
Sent: Sunday, November 10, 2019 10:00 AM
To: ARRL-LoTW@...
Subject: [ARRL-LoTW] TQSL 2.5 Release now available

The final release of TrustedQSL is now available. Once ARRL HQ staff pick up these images they'll be signed and published on the ARRL website. Windows users will be offered the update when it is published.

Release notes attached.

If you wish to get these immediately, they're published at the following links:

https://www.rickmurphy.net/lotw/tqsl-2.5.msi - Windows

https://www.rickmurphy.net/lotw/tqsl-2.5.dmg - 64-bit Mac

https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.dmg - 32 bit/PPC Mac

https://www.rickmurphy.net/lotw/tqsl-2.5.tar.gz - Linux, BSD, etc.

Thanks to everyone who helped with testing this version.

73,

-Rick
--
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA


Dave AA6YQ
 

+ AA6YQ comments below

2.4.7 is all I see when I check for updates. Am I missing something?

+ Yes, you are missing the second sentence of Rick K1MU's message appended below:

"Once ARRL HQ staff pick up these images they'll be signed and published on the ARRL website. Windows users will be offered the update when it is published."

+ Rick's message includes URLs on his personal web page that allow you to upgrade TQSL to 2.5 now.

73,

Dave, AA6YQ

On 11/10/19 11:50 AM, Dave AA6YQ wrote:
There are several improvements in this new version of TQSL that DXLab users will find useful; installation URLs are provided in Rick K1MU's message, appended below.

------------------------

When installing a Callsign Certificate, don't display errors about expired root certificates.

When listing DXCC entities, move the Deleted entities to the end of the list. This helps with the confusion between "Germany (DELETED)" and "FEDERAL REPUBLIC OF GERMANY", especially for persons where English is not a primary language. Allow the "DELETED" string in those names to be translated.

Eliminate the use of the term "duplicates" when referring to already uploaded QSOs as that term means something else in normal usage.

When editing a Station Location, do not force default values for station information fields. Only provide default values when a new station location is being created.

Fix incorrect ADIF output for several modes when creating files using the ADIF editor built into TQSL.

Use ARRL web service to validate US callsigns and pre-fill address info.

Fix TQSL updates failing on Windows when the user's home directory has non-ASCII characters.

Detect running TQSL "As Administrator" and warn the user. Allow this warning to be permanently overridden.

Verify that the TQSL working directory is writable during startup.

Disable prompting for callsign certificate password by default. Add a preference setting to allow this to be re-enabled if desired.

Fix error that was not overriding station location details with the default values when editing an existing station location.

Fix OSX error where the "Edit Station Location" icon was getting squashed.

Update "Waiting for Callsign Certificate" icon to a clock versus the slashed circle. The latter was being interpreted as something broken versus something to wait for.

Keep track of Callsign Certificate requests and reject attempts to request certificates for the same callsign more than 3 times in 24 hours. This limit will hopefully stop people from mistakenly re-requesting callsign certificates repeatedly for the same call because they don't realize that action needs to be taken by ARRL staff to complete the process.

Correct defect that could cause TQSL to crash upon exit while attempting to back up.

When requesting US 1x1 callsigns, which always require signing, don't ask for a certificate type for the request. Require that the user have a valid certificate for some other call to proceed. Remove the "1x1" callsign option from the certificate request type page.

When creating callsign certificates, ask for the type of certificate first as that then drives the next set of questions to ask.

Kudos to Rick K1MU!

73,

Dave, AA6YQ

-----Original Message-----
From: ARRL-LoTW@... [mailto:ARRL-LoTW@...] On Behalf Of Rick Murphy
Sent: Sunday, November 10, 2019 10:00 AM
To: ARRL-LoTW@...
Subject: [ARRL-LoTW] TQSL 2.5 Release now available

The final release of TrustedQSL is now available. Once ARRL HQ staff pick up these images they'll be signed and published on the ARRL website. Windows users will be offered the update when it is published.

Release notes attached.

If you wish to get these immediately, they're published at the following links:

https://www.rickmurphy.net/lotw/tqsl-2.5.msi - Windows

https://www.rickmurphy.net/lotw/tqsl-2.5.dmg - 64-bit Mac

https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.dmg - 32 bit/PPC Mac

https://www.rickmurphy.net/lotw/tqsl-2.5.tar.gz - Linux, BSD, etc.

Thanks to everyone who helped with testing this version.

73,

-Rick
--
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA



--
This email has been checked for viruses by AVG.
https://www.avg.com

Stan Gammons
 

On 11/10/19 11:22 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

2.4.7 is all I see when I check for updates. Am I missing something?

+ Yes, you are missing the second sentence of Rick K1MU's message appended below:

"Once ARRL HQ staff pick up these images they'll be signed and published on the ARRL website. Windows users will be offered the update when it is published."

+ Rick's message includes URLs on his personal web page that allow you to upgrade TQSL to 2.5 now.

Ok.  Maybe the subject stating it's available from Rick's site would have been better.   I think most will look on the Lotw site for a new version or try the update manually.


73

Stan
KM4HQE

Peter Laws
 

"Once ARRL HQ staff pick up these images they'll be signed and published on the ARRL website. Windows users will be offered the update when it is published."

+ Rick's message includes URLs on his personal web page that allow you to upgrade TQSL to 2.5 now.

I'd rather do it through the program itself. Any ETA on when HQ might
figure out how to put this in the right place on their VAX?


--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!

Dave AA6YQ
 

+ AA6YQ comment sbelow

"Once ARRL HQ staff pick up these images they'll be signed and published on the ARRL website. Windows users will be offered the update when it is published."

+ Rick's message includes URLs on his personal web page that allow you to upgrade TQSL to 2.5 now.

I'd rather do it through the program itself. Any ETA on when HQ might figure out how to put this in the right place on their VAX?

+ I have no insight into ARRL resource allocation or prioritization.

73,

Dave, AA6YQ

Andrew OBrien
 

“Final release “ ? Never updated again ?

Andy K3UK

On Nov 12, 2019, at 3:31 PM, Peter Laws <plaws0@...> wrote:



"Once ARRL HQ staff pick up these images they'll be signed and published on the ARRL website. Windows users will be offered the update when it is published."

+ Rick's message includes URLs on his personal web page that allow you to upgrade TQSL to 2.5 now.

I'd rather do it through the program itself. Any ETA on when HQ might
figure out how to put this in the right place on their VAX?


--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!


Dave AA6YQ
 

+ AA6YQ comments below

On Thu, Nov 14, 2019 at 06:16 AM, Andrew OBrien wrote:

“Final release “ ? Never updated again ?

+ I don't see the words "Final release" to which you are referring, but each new TQSL release like 2.5 is preceded by several "candidate releases" for testing. "Final release" refers to the last of these, which is made accessible via ARRL.

+ Unfortunately, a regression was detected in TQSL 2.5, so a new version will be necessary.

             73,

                     Dave, AA6YQ

 

 

C. Michael D'Alto
 

Since I updated to the latest TQSL through the notification I got from DXKeeper that it was available, I have been getting two error messages each time I start my applications through DXLab Launcher.  One is a popup that says "Administrator Error". . . "TQSL must not be run 'As Administrator'".  Three choices: 1) "Exit TQSL so I can re-run as a normal user."  2) "Allow TQSL to continue this time." 3) "Always allow running as Administrator."

The other error box popup says "DXKeeper: Updates from LoTW" TQSL is unable to contact LoTW.

If I start DXKeeper on its own WITHOUT Launcher, I DO NOT get any error messages.

If I turn off UAC Notifications I DO NOT get any error messages.

I made no other changes but to let the TQSL update through the program.

I never had any issues using DXLab Suite with Launcher prior to today.
I have successfully uploaded my daily contacts, synced my QSOs and QSLs today, so as long as I run launcher with UAC turned off (which I am not crazy about doing) it seems to be working fine. 

My OS is Windows 7 Home Premium SP1 x86, all current security updates.
DXLab has all the latest updates.

I'm not sure why this suddenly started happening.

Mike, K2CD

Dave AA6YQ
 

+ AA6YQ comemtns below

On Fri, Nov 15, 2019 at 09:11 PM, C. Michael D'Alto wrote:

Since I updated to the latest TQSL through the notification I got from DXKeeper that it was available, I have been getting two error messages each time I start my applications through DXLab Launcher.  One is a popup that says "Administrator Error". . . "TQSL must not be run 'As Administrator'".  Three choices: 1) "Exit TQSL so I can re-run as a normal user."  2) "Allow TQSL to continue this time." 3) "Always allow running as Administrator."

The other error box popup says "DXKeeper: Updates from LoTW" TQSL is unable to contact LoTW.

If I start DXKeeper on its own WITHOUT Launcher, I DO NOT get any error messages.

If I turn off UAC Notifications I DO NOT get any error messages.

I made no other changes but to let the TQSL update through the program.

I never had any issues using DXLab Suite with Launcher prior to today.
I have successfully uploaded my daily contacts, synced my QSOs and QSLs today, so as long as I run launcher with UAC turned off (which I am not crazy about doing) it seems to be working fine. 

My OS is Windows 7 Home Premium SP1 x86, all current security updates.
DXLab has all the latest updates.

I'm not sure why this suddenly started happening.

+ Do you have the Launcher configured to automatically start DXKeeper?

       73,

                Dave, AA6YQ

C. Michael D'Alto
 

+ Do you have the Launcher configured to automatically start DXKeeper?

Yes.  DXKeeper, DXView, Pathfinder, and SpotCollector.

These other options are selected.  Auto Start, Shutdown after termination, Use multiple monitors.
 
 

Dave AA6YQ
 

+ AA6YQ comments below

+ Do you have the Launcher configured to automatically start DXKeeper?

Yes. DXKeeper, DXView, Pathfinder, and SpotCollector.

These other options are selected. Auto Start, Shutdown after termination, Use multiple monitors.

+ OK. Using Windows Explorer, please navigate to your DXKeeper folder, and double-click on the entry for

DXKeeper.exe

+ Does the error message from TQSL appear?

73,

Dave, AA6YQ

John Kludt
 

Dave,

Gosh got the upgrade message yesterday at bootup of DXKeeper and did the upgrade - not issues I can detect.  Everything seems to be working normally.

By the way - a huge thank you for the work on SatPC32.  I had a most delightful day yesterday operating satellites and HF FT-8 between passes.  And all I had to do to toggle back and forth was click one little button on Commander,  Way cool!

John K4SQC



On Thu, Nov 14, 2019 at 12:50 PM Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

On Thu, Nov 14, 2019 at 06:16 AM, Andrew OBrien wrote:

“Final release “ ? Never updated again ?

+ I don't see the words "Final release" to which you are referring, but each new TQSL release like 2.5 is preceded by several "candidate releases" for testing. "Final release" refers to the last of these, which is made accessible via ARRL.

+ Unfortunately, a regression was detected in TQSL 2.5, so a new version will be necessary.

             73,

                     Dave, AA6YQ

 

 

C. Michael D'Alto
 

+ OK. Using Windows Explorer, please navigate to your DXKeeper folder, and double-click on the entry for

DXKeeper.exe

+ Does the error message from TQSL appear?

No, if I start DXKeeper directly from the DXKeeper directory it starts without the error messages.

If I start Launcher from the Launcher directory (instead of a shortcut on my desktop) I do get the error messages.

Dave AA6YQ
 

* more AA6YQ comments below

+ OK. Using Windows Explorer, please navigate to your DXKeeper folder, and double-click on the entry for

DXKeeper.exe

+ Does the error message from TQSL appear?

No, if I start DXKeeper directly from the DXKeeper directory it starts without the error messages.

If I start Launcher from the Launcher directory (instead of a shortcut on my desktop) I do get the error messages.


* When DXKeeper first starts, it directs TQSL to report any "news", like the imminent expiration of a Callsign Certificate or the availability of a new "Configuration Data" file.

* The latest version of TQSL includes this new functionality:

"Detect running TQSL "As Administrator" and warn the user. Allow this warning to be permanently overridden."

* In your first report, you said that when the DXLab Launcher starts DXKeeper, this error message is displayed:

"Administrator Error". . . "TQSL must not be run 'As Administrator'"

* and you are presented with three choices: 1) "Exit TQSL so I can re-run as a normal user." 2) "Allow TQSL to continue this time." 3) "Always allow running as Administrator."

* When you start DXKeeper directly, the error message does not appear.

* If you disable UAC Notifications, the error message does not appear.


* I see three possibilities:

1. Your desktop icon for the DXLab Launcher is starting the Launcher with Administrative privileges, which results in DXKeeper being started with Administrative privileges, which results in TQSL being started with Administrative privileges, which triggers the new functionality in TQSL.

2. The fact that DXKeeper has been started by the Launcher is somehow confusing the new "Administrative privileges detection" logic in TQSL.

3. The new "Administrative privileges detection" logic in TQSL is interacting with Window's UAC Notifications in an unexpected manner


* #2 seems unlikely, as no-one else has reported it either here or on the ARRL-LoTW Discussion Group.

* The next time the error message appears, you could choose "Always allow running as Administrator", but TQSL developer Rick K1MU (copied on this post) may want to investigate first.

73,

Dave, AA6YQ

C. Michael D'Alto
 

On Sat, Nov 16, 2019 at 10:43 AM, Dave AA6YQ wrote:
* I see three possibilities:

1. Your desktop icon for the DXLab Launcher is starting the Launcher with Administrative privileges, which results in DXKeeper being started with Administrative privileges, which results in TQSL being started with Administrative privileges, which triggers the new functionality in TQSL.
I think I eliminated this possibility when I start Launcher from with the Launcher directory instead of from the desktop icon.  I get the error messages either way, 

* and you are presented with three choices: 1) "Exit TQSL so I can re-run as a normal user." 2) "Allow TQSL to continue this time." 3) "Always allow running as Administrator."

What are the implications of always running as administrator, if I grant it?  Can it cause problems within the suite of DXLab programs, or it strictly a security liability?

I'm not too fond of running with UAC turned off. 

Mike

Dave AA6YQ
 

# AA6YQ comments below

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of C. Michael D'Alto via Groups.Io
Sent: Saturday, November 16, 2019 2:55 PM
To: DXLab@groups.io
Subject: Re: [DXLab] FW: [ARRL-LoTW] TQSL 2.5 Release now available

On Sat, Nov 16, 2019 at 10:43 AM, Dave AA6YQ wrote:


* I see three possibilities:

1. Your desktop icon for the DXLab Launcher is starting the Launcher with Administrative privileges, which results in DXKeeper being started with Administrative privileges, which results in TQSL being started with Administrative privileges, which triggers the new functionality in TQSL.

I think I eliminated this possibility when I start Launcher from with the Launcher directory instead of from the desktop icon. I get the error messages either way,

* and you are presented with three choices: 1) "Exit TQSL so I can re-run as a normal user." 2) "Allow TQSL to continue this time." 3) "Always allow running as Administrator."

What are the implications of always running as administrator, if I grant it? Can it cause problems within the suite of DXLab programs, or it strictly a security liability?

# Agreeing to "Always allow running as Administrator" does not mean "always running as administrator". It means that if you start TQSL with Administrative privileges, TQSL won't report an error as it has been doing when you start DXKeeper.

# Since you don't think you are starting DXKeeper or TQSL with Administrative privileges, that implies that there may be a defect in TQSL's logic that detects Administrative privileges. Rick K1MU, the developer of TQSL, is copied on this post.

73,

Dave, AA6YQ

C. Michael D'Alto
 

Thanks Dave.  I appreciate all your efforts.

Dave AA6YQ
 

# Even more AA6YQ comments below

On Sat, Nov 16, 2019 at 11:55 AM, C. Michael D'Alto wrote:

On Sat, Nov 16, 2019 at 10:43 AM, Dave AA6YQ wrote:
* I see three possibilities:

1. Your desktop icon for the DXLab Launcher is starting the Launcher with Administrative privileges, which results in DXKeeper being started with Administrative privileges, which results in TQSL being started with Administrative privileges, which triggers the new functionality in TQSL.
I think I eliminated this possibility when I start Launcher from with the Launcher directory instead of from the desktop icon.  I get the error messages either way, 

* and you are presented with three choices: 1) "Exit TQSL so I can re-run as a normal user." 2) "Allow TQSL to continue this time." 3) "Always allow running as Administrator."

What are the implications of always running as administrator, if I grant it?  Can it cause problems within the suite of DXLab programs, or it strictly a security liability?

I'm not too fond of running with UAC turned off. 

# Please terminate all of your DXLab applications. Using Windows Explorer, navigate to the Launcher's folder and run DXLabLauncher.exe . 

# When the Launcher starts, direct it to start DXKeeper.

# When DXKeeper starts, does TQSL complain about being started with Administrative privileges?

       73,

               Dave, AA6YQ

C. Michael D'Alto
 

# Please terminate all of your DXLab applications. Using Windows Explorer, navigate to the Launcher's folder and run DXLabLauncher.exe . 

# When the Launcher starts, direct it to start DXKeeper.

# When DXKeeper starts, does TQSL complain about being started with Administrative privileges?

Yes it does.

73, Mike