News for hackers. Stuff that matters.
Re:Electron apps cannot be submitted to the Apple store by ivan_gammel on Monday November 04, 2019 @12:22AM (#21439233)
as CTO I know all the dependencies in the application stack of our company and I require developers to have sufficient understanding of their purpose, licensing model etc. There are tools to simplify this task. It’s much harder to do for TypeScript than for Java, mostly because NPM ecosystem is a huge pile of junk, but it’s still important part of developer's job.
Re:Electron apps cannot be submitted to the Apple store by root_axis on Monday November 04, 2019 @12:36AM (#21439281)
> as CTO I know all the dependencies in the application stack of our company

You know all of the transitive dependencies in the application stack of your company? Out of curiosity, what is the ballpark figure on the total number of transitive dependencies in your application?

Re:Electron apps cannot be submitted to the Apple store by ivan_gammel on Monday November 04, 2019 @08:02AM (#21441210)
Hundreds, mostly because of the JS nonsense. Our Java microservices are lean and strictly controlled.
Re:Electron apps cannot be submitted to the Apple store by nl on Monday November 04, 2019 @07:12AM (#21440875)
as CTO I know all the dependencies in the application stack of our company

I'm a few years out of the Java world these days, but you've vetted every line in every one of those Apache commons projects that gets pulled in? Because that's a lot of reading...

Over 10 years ago I went through every single Java RSS parsing library and all their forks (I think there were 5) to fix Xml eXternal Entity (XXE) attacks (eg[1]) and submitted fixes for them all.

That was a huge amount of work, because they all used random version of different XML parsers, all of which required external entity processing to be turned off in different ways.

None of the authors of the packages were aware of the issue, and as far I could determine at the time I was the only person in the entire Java ecosystem who knew all the different parsers arguments.

This was a critical, remotely exploitable vulnerability. I'd never claim to know about it now, and it was only for a few weeks back in 2006 that I really knew it then.

So when you say you "know" all the dependencies in your stack, what do you mean exactly?

[1] https://rometools.jira.com/browse/ROME-46

Re:Electron apps cannot be submitted to the Apple store by ivan_gammel on Monday November 04, 2019 @08:01AM (#21441196)
We barely have any of the Apache commons dependencies - in most cases use of them is not justified in modern Java. If there’s anything like that we are ready to support such dependency on source code level, patching and setting up own build pipeline if necessary. Free software cannot be trusted if you are not ready to own it. Commercial software cannot be trusted either, but there are other ways to manage the risks there.
Re:Electron apps cannot be submitted to the Apple store by fookitty on Monday November 04, 2019 @01:10PM (#21444473)
I can't believe you check all the source code, dependencies source code and the rest of the shit show that npm brings to the party, that's very cool, all CTOs should be like you. As a CTO should you have to do this though? I'm not sure.
Re:Electron apps cannot be submitted to the Apple store by ivan_gammel on Tuesday November 05, 2019 @01:08AM (#21450082)
We are growing startup and it’s important to have this culture of understanding what and how you build from the very beginning. This responsibility is now transferred to technical leads, but I’m still aware of what’s going on and spend some time on the code reviews.
Re:Electron apps cannot be submitted to the Apple store by imtringued on Tuesday November 05, 2019 @07:44AM (#21451842)
How much time does it take to read through the millions of lines of code?
Re:Electron apps cannot be submitted to the Apple store by diggan on Thursday November 07, 2019 @06:48AM (#21472319)
Usually you don't write a project and then sit down to read through all dependencies, but it's a process that happens when you do add a dependency.

So, the process would be something like: have a problem that a library might solve, find a library that could solve the problem, verify it can solve the problem, look through the implementation, look through it's dependencies, then actually include it in the build. If anything doesn't look nice at each step, rollback and find something else or start writing your own implementation.

Do this from beginning of the project and you'll always have a full understanding of the system.