Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 44

Thread: 4.9 Jar signing??

  1. #21
    Join Date
    Oct 2020
    Posts
    5
    Post Likes
    Quote Originally Posted by MaxBurn View Post
    They require the email to sign up but there is no follow through validation of the email so you can just make something up and as long as you don't need to reset you are all set.
    Hey everyone I'm Adam from the NiagaraMods site. We're hosting the files as a courtesy to our users which is why we require a sign up to download. We provide a lot of free content back to the community and all we ask for are some legit contact details code signing certs and file hosting aren't free for us so we'd like to email you when we have something new to share. We'd appreciate it if you'd provide legit info if you plan on using our site we don't send emails often and don't share your data with anyone.

  2. #22
    Join Date
    May 2008
    Location
    United Kingdom
    Posts
    47
    Post Likes
    Hi nmodsadam, and thanks for the reply
    Can I ask why only the xxx-rt file is signed and not the other files associated with the modules, as shown by my controller, or have I installed them wrong,
    thanks

  3. #23
    Join Date
    Oct 2020
    Posts
    5
    Post Likes
    Quote Originally Posted by yorkisn View Post
    Hi nmodsadam, and thanks for the reply
    Can I ask why only the xxx-rt file is signed and not the other files associated with the modules, as shown by my controller, or have I installed them wrong,
    thanks
    Hey. I just downloaded and tested fresh on 4.9 and they all appear signed in my Workbench. Maybe the files weren't overwritten properly if you had them installed previously? You also might want to make sure shutdown WB and any running station before copying the modules.

  4. #24
    Join Date
    Oct 2020
    Posts
    5
    Post Likes
    Quote Originally Posted by MaxBurn View Post
    Trusting more people and lengthening the supply chain isn't a security improvement.
    We agree whole-heartedly with this. Unfortunately this is the situation we're in with code signing for Niagara today.

    Regarding validation, we just ran the current build available on the official repo (R243) through the JAR signing utility. You should be able to extract any binary file from the JAR and see they match (and even have the same modified date as) the files on SourceForge. Unfortunately it won't be this easy for future builds as the maintainers will no longer be releasing compiled versions of the module so we will need to compile it ourselves and it won't give users anything to verify against. Trust is important here.

  5. #25
    Join Date
    May 2009
    Location
    SC
    Posts
    2,431
    Post Likes
    Quote Originally Posted by nmodsadam View Post
    We agree whole-heartedly with this. Unfortunately this is the situation we're in with code signing for Niagara today.

    Regarding validation, we just ran the current build available on the official repo (R243) through the JAR signing utility. You should be able to extract any binary file from the JAR and see they match (and even have the same modified date as) the files on SourceForge. Unfortunately it won't be this easy for future builds as the maintainers will no longer be releasing compiled versions of the module so we will need to compile it ourselves and it won't give users anything to verify against. Trust is important here.
    Thanks for checking in here. To be clear I'm not attacking you or the site, I think community pulling together like this is great. I'm just pointing out that the end results of this situation seem to be the exact opposite of the intended goal.

  6. #26
    Join Date
    Oct 2020
    Posts
    5
    Post Likes
    Quote Originally Posted by MaxBurn View Post
    Thanks for checking in here. To be clear I'm not attacking you or the site, I think community pulling together like this is great. I'm just pointing out that the end results of this situation seem to be the exact opposite of the intended goal.
    Definitely not taking it that way – we appreciate it and appreciate you discussing our content! Hopefully you'll find more useful things on our site than just the community module

  7. #27
    Join Date
    Jan 2003
    Location
    USA
    Posts
    5,638
    Post Likes
    Quote Originally Posted by nmodsadam View Post
    the maintainers will no longer be releasing compiled versions of the module so we will need to compile it ourselves and it won't give users anything to verify against.
    Hmm. Sounding more and more like that jar may need to fade away.

    Seems like this has the potential to turn into a real mess. Say a customer requires this and is serious about it. Now you got these questionable jars with legit signatures floating around in the eco system. Not just AX comm, but any stupid little add on some system provider thought would be cool and well because they can. If its useful and not licensed, that get passed around. AX Comm is running around with 50 different certs on it, can't verify any of them... Next guy signs everything in a takeover case and can't be bothered to strip out random crap that now needs to be signed. Signs it all and that gets passed forward in the next takeover.

    All green running station has little meaning then. One has to analyze the installed modules and certs to keep them out at that point. Could turn a dumpster fire.
    Last edited by orion242; 10-15-2020 at 08:32 PM.
    Propagating the formula. http://www.noagendashow.com/

  8. Likes MaxBurn liked this post.
  9. #28
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    2,362
    Post Likes
    For as many years as I been seeing the warning about unsigned programs in the AppDir, it does not seem like this was thought through too well.
    I have a university with dozens of unsigned program blocks strewn randomly through nearly every one of over 30 stations, doin useless crap like latching an alarm to make and end user specifically unlatch it so the machine will run... so useless....
    Anyway, it seems like there was an IT pro feeding Tridium a best practices checklist and it was thoughtlessly implemented and it IMMEDIATELY goes sideways as the world scrambles to gets the 'secure' ideal to meet the real world.
    On the other hand, if you are the Controls company who can blindly certify all the usless program objects and convert that AX station to N4 without having to rebuild it... you just cut the amount of programming time in half and have landed the contract over the other guy.
    When handed lemons make lemonade....
    Hmmmm....smells like numbatwo to me.

  10. #29
    Join Date
    Oct 2020
    Posts
    5
    Post Likes
    Quote Originally Posted by orion242 View Post
    Hmm. Sounding more and more like that jar may need to fade away.

    Seems like this has the potential to turn into a real mess. Say a customer requires this and is serious about it. Now you got these questionable jars with legit signatures floating around in the eco system. Not just AX comm, but any stupid little add on some system provider thought would be cool and well because they can. If its useful and not licensed, that get passed around. AX Comm is running around with 50 different certs on it, can't verify any of them... Next guy signs everything in a takeover case and can't be bothered to strip out random crap that now needs to be signed. Signs it all and that gets passed forward in the next takeover.

    All green running station has little meaning then. One has to analyze the installed modules and certs to keep them out at that point. Could turn a dumpster fire.
    We're in interesting times that's for sure. You're right on the money though we'll have to see how the ecosystem evolves to handle this. Personally, I hope this jar and others like it don't fade away. The openness and extendibility of Niagara is what drew me to it as a developer. It would be a shame to lose the amazing work independent developers have to come up with and I hope people continue to put stuff out there (I know we plan to).

    I try to keep in mind that running any compiled third-party code requires trust in the source I get it from, this was the case before signing was a thing and remains the same after.

    Code signing brings a benefit of independent identity verification but that's really it you know code signer isn't lying about their identity but you still have to trust them and the code. While I think that verification is important, I do see how it can provide a false sense of security (especially for building owners who don't understand this stuff) and making it a requirement seems to be a huge pain and time sink for integrators trying to get their jobs done.

    On the other hand, I can see why this was done from Tridium's POV. It adds a barrier to entry for would-be malicious software developers and most platforms these days have some form of code signing requirement (Android, iOS, macOS, etc). For platforms that are so extendable and open to developers code signing seems to be the new normal.

  11. #30
    Join Date
    Jan 2003
    Location
    USA
    Posts
    5,638
    Post Likes
    Quote Originally Posted by nmodsadam View Post
    we'll have to see how the ecosystem evolves to handle this.
    Indeed
    Quote Originally Posted by nmodsadam View Post
    I try to keep in mind that running any compiled third-party code requires trust in the source I get it from, this was the case before signing was a thing and remains the same after.
    That is how it should be. I get a driver from Maxline and its signed by them. When things are floating around signed by 2-3 parties removed from original developer or by the Hong Kong post office, now things are heading south.
    Quote Originally Posted by nmodsadam View Post
    making it a requirement seems to be a huge pain and time sink for integrators trying to get their jobs done.
    The dumpster, fuel, and ignition imo. Making it required. Numba’s example above. A system provider could easily spend 100+ hrs trying to remove the useless crap in a station or spend ~$100, few hours of labor and just sign it all and move on. The financial incentive is totally counter to the end goal.

    I do not think the PKI/Niagara world is ready for hundreds or thousands of controls contractors running around singing things.
    Quote Originally Posted by nmodsadam View Post
    For platforms that are so extendable and open to developers code signing seems to be the new normal.
    Glad they added it. Generally, it seems like a good idea. Making it required is where I think some unintended consequences are likely. Its a really low bar to meet and the flip side can be labor intensive. Thoughts of every outfit operating out of their garage singing things in the eco system, hmm. What are we really getting into here??
    Last edited by orion242; 10-16-2020 at 07:44 AM.
    Propagating the formula. http://www.noagendashow.com/

  12. #31
    Join Date
    Jul 2009
    Location
    Wa
    Posts
    525
    Post Likes
    Thread Starter
    Well, I'm glad I started this thread. Not knowing all I should about this subject this has brought up a lot of different thoughts. I agree with this being required is a potential bomb, and would like to hear what other systems are doing with this? Like what is Delta, ALC, Trane and others? I got to believe that all systems in some manner will have to deal with this? I just wonder because the T-BOX is a one stop shop for all, and its openness regarding your own development was a real advantage. Now its like, well you guys developed all these cool things, and here is your punishment for doing so!!

  13. #32
    Join Date
    May 2009
    Location
    SC
    Posts
    2,431
    Post Likes
    Quote Originally Posted by Norriski Tech View Post
    , and would like to hear what other systems are doing with this? Like what is ~, ALC,
    The structure of the ALC platform is completely different from Tridium first of all, nobody is allowed to make a third party program that can load and run in ALC hardware and I don't see that changing. Which is a shame because man we need some drivers. ALC addons run in the supervisory server and can interact with the field controllers but have the resources of a PC to work with. Currently and on the next version signing can be turned off. Currently and on the next version and likely after that you can sideload your dev cert to allow you to upload addons through the web interface without issues. Addon signing doesn't and likely won't ever auth against the underlying OS cert store.

    The more useful things I'm seeing security wise is the Tridium security dashboard that just came out, that is a really useful dashboard. Good info, easily found and easy to understand that something is bad. ALC's sreview in the next version has something that aspires to this but it's hidden and hard to understand.

  14. #33
    Join Date
    Jul 2009
    Location
    Wa
    Posts
    525
    Post Likes
    Thread Starter
    Quote Originally Posted by MaxBurn View Post
    The structure of the ALC platform is completely different from Tridium first of all, nobody is allowed to make a third party program that can load and run in ALC hardware and I don't see that changing. Which is a shame because man we need some drivers. ALC addons run in the supervisory server and can interact with the field controllers but have the resources of a PC to work with. Currently and on the next version signing can be turned off. Currently and on the next version and likely after that you can sideload your dev cert to allow you to upload addons through the web interface without issues. Addon signing doesn't and likely won't ever auth against the underlying OS cert store.

    The more useful things I'm seeing security wise is the Tridium security dashboard that just came out, that is a really useful dashboard. Good info, easily found and easy to understand that something is bad. ALC's sreview in the next version has something that aspires to this but it's hidden and hard to understand.
    Thanks for the reply. I guess that's what I was alluding to is that those type systems ALC, Trane, Delta and many others aren't really dealing with this on the level Tridium people are. I guess what gave the jace an advantage in it's drivers capabilities and openness for development by others has created somewhat of what of disadvantage compared to competitor's in todays signing world.

  15. #34
    Join Date
    Jan 2003
    Location
    USA
    Posts
    5,638
    Post Likes
    Simple is not flexible and flexible is not simple.

    Tridium is really pushing security forward on these systems. Probably leading that in many ways with secure boot, code signing, etc.

    Some customers I am sure are demanding it. Warheads on foreheads folks, financial, pharma, etc. Pushing it everywhere is where things might get a bit crazy before the dust settles.
    Propagating the formula. http://www.noagendashow.com/

  16. #35
    Join Date
    May 2009
    Location
    SC
    Posts
    2,431
    Post Likes
    That must be it, Tridium is sol sourced in a lot of government work.

    You listen to Risky Biz as well?

  17. #36
    Join Date
    Jan 2003
    Location
    USA
    Posts
    5,638
    Post Likes
    Quote Originally Posted by MaxBurn View Post
    You listen to Risky Biz as well?
    Of course and that makes me smile every time. Normally the code I hear around here is 'delivering freedom'.
    Propagating the formula. http://www.noagendashow.com/

  18. Likes MaxBurn liked this post.
  19. #37
    Join Date
    Jan 2003
    Location
    USA
    Posts
    5,638
    Post Likes
    So fiddling around with this process in Niagara and diving in the docs, looks like I had some of the info wrong.

    docModuleSign

    Verification modes

    • Low — Any modules that are not signed or are signed with an untrusted or expired certificate will cause warnings but will still function normally. Errors will occur if a signed module is modified after it was signed and installation of such modules is not allowed.
    • Medium — All modules must be signed by a valid, trusted certificate, but this certificate can be selfsigned. Installation of unsigned or invalidly signed modules is not allowed.
    • High — All modules must be signed with a CA signed certificate. An internal CA can be used, but in this case, the CA certificate must be imported into the user trust store. Installation of modules signed with self-signed certificates is not allowed.


    Staged roll-out

    • Niagara 4.8 — Default verification mode is Low. Customers can increase the verification mode as needed for testing or to improve security posture.
    • Niagara 4.9 — Default verification mode is Medium. Customers can decrease the verification mode to “low” if they are not ready for module signing yet, or up to “high” if they want to enforce more strict requirements.
    • Niagara 4.10+: Default verification mode is High. Customers can decrease verification mode to “medium” if they still have some modules signed with self-signed certificates. Decreasing verification mode to “low” will no longer be allowed except for developer customers.


    Shouldn't be a huge need for going through the hassle of getting a legit cert for some time, if ever. In 4.10 on you will need to selfie sign everything at minimum. That's a bit more reasonable than what I had thought which was everything required legit certs, aka high mode only.

    Get axcom selfie sign it yourself and your good. This will show up with the yellow icon in the software manager, security dashboard, etc but it will run.

    Path of least resistance. Drop verification to medium and get familiar with the signing tools within WB when 4.10 rolls out.
    Propagating the formula. http://www.noagendashow.com/

  20. Likes DigitalScars liked this post.
  21. #38
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    2,362
    Post Likes
    Sounds like you just saved everyone on the thread several hours of fiddling a least Orion. Thanks for the post. GREATLY appreciated!
    Hmmmm....smells like numbatwo to me.

  22. #39
    Join Date
    Jan 2003
    Location
    USA
    Posts
    5,638
    Post Likes
    Quote Originally Posted by numbawunfela View Post
    Sounds like you just saved everyone on the thread several hours of fiddling
    Doubt that. Just pointing out a lgeit cert is not require in 4.10 and it doesn't sound like that will change. Its typical Niagara, all the info is scattered about. What looks to be complete never covers what your trying to do.

    Importing certs into Niagara still the same hassle as I remembered. Thought I heard they improved this. Everything has to be just so, or its cryptic errors.

    Program object signing, you need to set your signing cert under tools - options. Then it will just happen when you compile them.
    Propagating the formula. http://www.noagendashow.com/

  23. #40
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    2,362
    Post Likes
    Quote Originally Posted by orion242 View Post
    Doubt that.
    Its typical Niagara, all the info is scattered about. What looks to be complete never covers what your trying to do.
    ... Everything has to be just so, or its cryptic errors.
    I don't doubt it.
    For the reasons you laid out.
    Thanks again.
    Hmmmm....smells like numbatwo to me.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •