Dev 1.1.3 as Next Stable Release

[ExtremeFiretop]

Dev 1.1.3 as Next Stable Release

What's Changed/Fixed?:

PR: #201 - Node MinorLogicFix and Default Schedule

This is a fix related to the last release in 1.1.2 where we patched this issue identified below:
-Additionally, the new code for email notifications for nodes could also potentially pause the cron job when sending an email notification.

I did fix it with a quick patch/fix in 1.1.2, but by working around the issue to get a quick fix out the door, the current 1.1.2 release can't process the direct call to process the nodes for example:

I identified the root cause of the issue and resolved it in this PR (#201)

We also changed the default schedule from: Every SUNDAY: 0 0 * * Sun To EVERYDAY: 0 0 * * *
The original schedule of every Sunday wasn't ideal for a newbie user that doesn't understand all the features and switches yet.

PR: #202 - General Code improvements.

Minor code improvements and cleanup in the "GetAllNodeSettings " function. (Thanks @Martinski4GitHub)!
PR: #203 - Code change to address script file path issue

This PR is all about the issue reported by @aex.perez in this forum post . (Thanks @Martinski4GitHub)!
While we weren't able to replicate the issue, we hope this small change in the logic and order of operations will address your issue. If you notice this issue again please report it.

PR: #204 - Include New Logs Menu

Router and node with cron offsets
Option to download the latest log file
Email notification now contains the changelog contents flagged
Designed a new logs menu for log options found below:

We also added a 15 minute offset to the default schedule if MerlinAU is installed on a node.

if "$inRouterSWmode"
then
    readonly FW_Update_CRON_DefaultSchedule="0 0 * * *"
else
    readonly FW_Update_CRON_DefaultSchedule="15 0 * * *"
fi

PR: #205 - Include Cron Estimates
As requested by @viktor Jaep and @nlurker in this forum post

We now provide an exact estimate of when the next update will run down to the date and minutes when an update is found.

The old method did not factor in the cron job schedule and only factored based on the delay/postpone time.

PR: #206 - New menu option to view F/W Update log files.

Added a new menu option that allows users to review a F/W Update log file. Only the most recent 20 log files are listed for selection. (Thanks @Martinski4GitHub)!

PR: #207 - Minor Wording Cleanup

Minor change in email notification wording depending if it's installed on a router or node. This was a change recommended by @maghuro in this forum post

if "$inRouterSWmode"
then
printf "\n ${GRNct}em${NOct}.  Toggle F/W Update Email Notifications"
else
printf "\n ${GRNct}em${NOct}.  Toggle F/W Email Notifications"
fi

PR: #208 - Fix Future Estimates
Redesigned PR: 205 to fix issues with specific crons schedules not being parsed and calculated correctly and be generally cleaner to work on and read.
PR: #209 - Fixes, code cleanup & improvements

Again, fixed released to PR: 205 to fix issues with specific crons schedules not being parsed and calculated correctly and be generally cleaner to work on and read. (Thanks @Martinski4GitHub)!
PR: #210 - More Code improvements for PR: #205 and PR :#209

Martinski cleaning up some of his code from PR 209 to make it easier and cleaner to read (Thanks @Martinski4GitHub)!
Just... So much Tightening... So much code... (improvements).
If you haven't noticed already we highly recommend you update ASAP as this includes lots of functional improvements and little bug fixes.

[ExtremeFiretop]

@Martinski4GitHub

Seems like more requests coming in, I know you wanted to change the main menu, I'm thinking that can probably be addressed in the next release with the additional changes being requested, it seems like our work isn't over anyways ;)

(i.e

1. Changelog notifications earlier before the attempted update run
2. Sanity check the sha265 with the merlin website
3. your additional changes to the menu)

The changelog for this release is getting long so I think it's time to send off and we can focus on the new changes without a hushle

[Martinski4GitHub]

@Martinski4GitHub

Seems like more requests coming in, I know you wanted to change the main menu, I'm thinking that can probably be addressed in the next release with the additional changes being requested, it seems like our work isn't over anyways ;)

(i.e

1. Changelog notifications earlier before the attempted update run

I don't know what that is about - probably because I haven't been keeping up with all the SNB Forums posts.

2. Sanity check the sha265 with the merlin website

That sounds like a great idea. It's always good to separate the payload from the SHA256 signature proving its authenticity & integrity.

3. your additional changes to the menu)

Here's a screenshot of what I was talking about yesterday WRT changing the wording of the items on the top section of the Main Menu.

As mentioned, this is a proposed alternative that allows us to be much clearer what each item is about. Let me know your thoughts.

[ExtremeFiretop]

@Martinski4GitHub
Seems like more requests coming in, I know you wanted to change the main menu, I'm thinking that can probably be addressed in the next release with the additional changes being requested, it seems like our work isn't over anyways ;)
(i.e

1. Changelog notifications earlier before the attempted update run

I don't know what that is about - probably because I haven't been keeping up with all the SNB Forums posts.

No worries this is the post where this was discussed:

https://www.snbforums.com/threads/merlinau-v1-1-3-the-ultimate-firmware-auto-updater-now-available-in-amtm.88577/post-907514

Basically, if an update is detected, check instantly for high risk phrases even in the postpone period.
(I'm thinking we piggy back on our new logic to download the changelog on demand)

Then it can send an email and advise instantly that high risk phrases will be found within the postpone period, the user can then approve the flash at anytime within the postpone period, and at the time of the flash it just has to check to make sure the flash was approved, else it does what it currently does and exits or prompts for approval if interactive.

2. Sanity check the sha265 with the merlin website

That sounds like a great idea. It's always good to separate the payload from the SHA256 signature proving its authenticity & integrity.

It came from @dave14305 here: https://www.snbforums.com/threads/merlinau-v1-1-3-the-ultimate-firmware-auto-updater-now-available-in-amtm.88577/post-908427

And I think it's a good idea, basically increases the robustness and removes a potential for a "vulnerability" if somehow RMerlin's SF was ever hacked.

3. your additional changes to the menu)

Here's a screenshot of what I was talking about yesterday WRT changing the wording of the items on the top section of the Main Menu.

As mentioned, this is a proposed alternative that allows us to be much clearer what each item is about. Let me know your thoughts.

I really like the idea, honestly at this point I think it's going to be hard to get all the info we need/want within that tiny top header, expanding it like you did is not a bad idea and looks just as good in my eyes.

[ExtremeFiretop]

@Martinski4GitHub

Right now the tiny header matches the length with our logo, did you happen to adjust/modify that?

[Martinski4GitHub]

@Martinski4GitHub
Seems like more requests coming in, I know you wanted to change the main menu, I'm thinking that can probably be addressed in the next release with the additional changes being requested, it seems like our work isn't over anyways ;)
(i.e

1. Changelog notifications earlier before the attempted update run

I don't know what that is about - probably because I haven't been keeping up with all the SNB Forums posts.

No worries this is the post where this was discussed:

https://www.snbforums.com/threads/merlinau-v1-1-3-the-ultimate-firmware-auto-updater-now-available-in-amtm.88577/post-907514

Basically, if an update is detected, check instantly for high risk phrases even in the postpone period. (I'm thinking we piggy back on our new logic to download the changelog on demand)

Then it can send an email and advise instantly that high risk phrases will be found within the postpone period, the user can then approve the flash at anytime within the postpone period, and at the time of the flash it just has to check to make sure the flash was approved, else it does what it currently does and exits or prompts for approval if interactive.

OK, I see. Essentially, they want a way to pre-approve the F/W flash in cases when the "Changelog Check" option has been enabled & "high-risk phrases" are found so that when the actual F/W update run happens, it no longer stops for approval.

2. Sanity check the sha265 with the merlin website

That sounds like a great idea. It's always good to separate the payload from the SHA256 signature proving its authenticity & integrity.

It came from @dave14305 here: https://www.snbforums.com/threads/merlinau-v1-1-3-the-ultimate-firmware-auto-updater-now-available-in-amtm.88577/post-908427

And I think it's a good idea, basically increases the robustness and removes a potential for a "vulnerability" if somehow RMerlin's SF was ever hacked.

Well, it doesn't completely remove the potential risk but it does make it harder to pull off because two places must be hacked to modify the SHA256 signatures.

3. your additional changes to the menu)

Here's a screenshot of what I was talking about yesterday WRT changing the wording of the items on the top section of the Main Menu.
...
As mentioned, this is a proposed alternative that allows us to be much clearer what each item is about. Let me know your thoughts.

I really like the idea, honestly at this point I think it's going to be hard to get all the info we need/want within that tiny top header, expanding it like you did is not a bad idea and looks just as good in my eyes.

OK, I'll submit a PR with the changes.

[Martinski4GitHub]

@Martinski4GitHub

Right now the tiny header matches the length with our logo, did you happen to adjust/modify that?

I'm not sure what you mean by the "tiny header."
Are you referring to the "separator line" composed of equal signs & our name handles located between the logo and the top section of the Main Menu?

[ExtremeFiretop]

@Martinski4GitHub
Right now the tiny header matches the length with our logo, did you happen to adjust/modify that?

I'm not sure what you mean by the "tiny header." Are you referring to the "separator line" composed of equal signs & our name handles located between the logo and the top section of the Main Menu?

Not exactly, I mean the "top section" of the main menu is the "header" of the menu/script and the original version of the header was a "tiny" version of the header compared to how you extended it now. Now I guess it's a "bigger header?" 🤣

It used to line up with the equal lines in the logo, has this been adjusted at all to now match your "bigger header?" Hehe

[ExtremeFiretop]

Well, it doesn't completely remove the potential risk but it does make it harder to pull off because two places must be hacked to modify the SHA256 signatures.

I think the idea is it's safer since they would need to hack both locations, as I mentioned in the forums nothing is a zero risk, no matter how safe we are or RMerlin is.

But with this change if they hack SF it wouldn't match the website sha256, right now if they hacked the SF alone it would be slipped by.

[Martinski4GitHub]

@Martinski4GitHub
Right now the tiny header matches the length with our logo, did you happen to adjust/modify that?

I'm not sure what you mean by the "tiny header." Are you referring to the "separator line" composed of equal signs & our name handles located between the logo and the top section of the Main Menu?

Not exactly, I mean the "top section" of the main menu is the "header" of the menu/script and the original version of the header was a "tiny" version of the header compared to how you extended it now. Now I guess it's a "bigger header?" 🤣

It used to line up with the equal lines in the logo, has this been adjusted at all to now match your "bigger header?" Hehe

OK, I've submitted the PR with the changes to the top section/header. Take a look and see how the entire Main Menu looks on your screen. I think I know what you mean but better to see it "live." I was a bit confused because "tiny" to me means something very small or extremely small so I could not relate it to anything on the screen except for the "separator line" composed of equal signs. Note the other secondary menus were not changed at all WRT the "separator lines."

[Martinski4GitHub]

Well, it doesn't completely remove the potential risk but it does make it harder to pull off because two places must be hacked to modify the SHA256 signatures.

I think the idea is it's safer since they would need to hack both locations, as I mentioned in the forums nothing is a zero risk, no matter how safe we are or RMerlin is.

But with this change if they hack SF it wouldn't match the website sha256, right now if they hacked the SF alone it would be slipped by.

Oh yeah, I get it. In the company I work for we have the same strategy & similar mechanism to be able to validate the authenticity & integrity of all our software installers, and that's in addition to each installer containing a built-in digital signature. So there's no objection from me to making the SHA256 verification process much safer. My comment was simply to point out that we cannot say that the potential problem is "removed" because it can only be mitigated by making it more difficult for a hacker to hack two places instead of just one.

[ExtremeFiretop]

@Martinski4GitHub
Right now the tiny header matches the length with our logo, did you happen to adjust/modify that?

I'm not sure what you mean by the "tiny header." Are you referring to the "separator line" composed of equal signs & our name handles located between the logo and the top section of the Main Menu?

Not exactly, I mean the "top section" of the main menu is the "header" of the menu/script and the original version of the header was a "tiny" version of the header compared to how you extended it now. Now I guess it's a "bigger header?" 🤣
It used to line up with the equal lines in the logo, has this been adjusted at all to now match your "bigger header?" Hehe

OK, I've submitted the PR with the changes to the top section/header. Take a look and see how the entire Main Menu looks on your screen. I think I know what you mean but better to see it "live." I was a bit confused because "tiny" to me means something very small or extremely small so I could not relate it to anything on the screen except for the "separator line" composed of equal signs. Note the other secondary menus were not changed at all WRT the "separator lines."

No worries my friend, you can ask for clarification anytime without problem I'll just always try to rephrase it clearify knowing we can't call to clear the air.

Sorry for the delay I had to head off to bed my day was nuts and I had zero energy by midnight haha 😂

I saw the PR and approved it, I do see you matched the logo with the new header size, I guess I'll check into the other menus to see if we can match if all up!