Connect with us

Tech

Cull your dependencies

Published

on

Anyone writing code professionally in December 2021 will remember the “fun” of the Log4J vulnerability. This was a serious security flaw that allowed hackers to execute any code on your servers. Log4J is a Java-based logging library. This is what caused the problem.

It is used to create code like

log.info("Process completed successfully");

which will appear in your logs and allow you to track the behaviour of your application. It’s pretty simple stuff.

My company was one of the affected by the vulnerability (among countless others), and in looking into it I noticed something.

By the numbers

The underlying Log4J library is 168,000 lines of code.

Most commercial applications import hundreds of these packages. This amounts to approximately 1M lines of code. This is roughly the size of an entire operating system.

In Code Complete Steve McConnell estimates that commercial software has roughly 15-50 errors per thousand lines of code.

For our hypotheical application with 1M LoC in its dependences, this suggests we’d have around 15,000 bugs in imported code alone. You will not likely ever see, read, or even think about code.

Assumptions developers make

An interesting thing about developers is that we are lazy, and prefer to write as few lines of code as possible, sticking rigidly to the principle of “not reinventing the wheel”. This encourages developers to use packages to solve common problems rather than writing a utility class or method from scratch. However, this habit often results in the addition of thousands of lines to your dependencies, to save writing 20 lines yourself.

We assume code supplied via official channels (maven or npm, pip etc.) will be better quality. It’s obvious that the code has come from the package manager. In reality, packages are usually maintained by one person or a small group of volunteers. Packages added to package managers are not subject to quality checks. Log4J has been in production for nearly 20 years, and practically every version of it has contained the critical issue that kept many of us busy patching it in December.

Just because it has been “battle-tested” in production systems, does not mean it is secure. These two assumptions create a toxic mix in which developers, despite their best intentions, add more code of unknown quality to applications in an attempt to speed up development and reduce code reuse.

Process problems

Once a package has been added, it becomes part of your “assumed standard” — people will assume that using it safe, and that to do so is best practice, so it will proliferate. As usage increases, the dependency will become more solidified and calcified, making it difficult to remove without major engineering efforts.

Minimising dependencies is not something that’s (currently) widely valued in our industry, and putting in the refactoring effort to remove a dependency almost never happens (the only exception I’ve seen is the removal of Log4J, which is relatively easy to replace, and was only done after a truly massive incident). Over the life of a piece, dependencies will continue to grow and vulnerability will slowly accumulate in the software.

Additionally, even if you remove a method from being used in code, tooling to remove the package it came from from your project’s imports (via pom.xml, package.json, etc.) It is very poor. It is difficult to know if you actually need the package or if it has other functionality that is still being used in another part of your codebase. Stale packages can become bloat and are just waiting for an uninformed developer to reintroduce them.

Proposals

  1. As a rule, do not add dependencies to your codebase.
  2. When a new package is added to the codebase, demand full justifications about why it is required, and record the reason for the addition in a log within the repository. It will be easier to remove the dependency if necessary and it will also help to ensure that it is used only for its intended purpose.
  3. Don’t import multiple packages for “utility methods” – use one and explicitly agree on using it as a standard within your team. You should record this decision in the dependencies log.

I will follow these guidelines in my team and projects. Are you in agreement with these? Let me know if you do, or if there are other techniques you follow to prevent dependency proliferation in your work.

Read More

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published.

Tech

USB logos finally make sense, thanks to a redesign

Published

on

By

USB logos finally make sense, thanks to a redesign


Author: Mark Hachman
, Senior Editor

As PCWorld’s senior editor, Mark focuses on Microsoft news and chip technology, among other beats. He has formerly written for PCMag, BYTE, Slashdot, eWEEK, and ReadWrite.

Read More

Continue Reading

Tech

Cheaper OLED monitors might be coming soon

Published

on

By

Cheaper OLED monitors might be coming soon


Author: Michael Crider
, Staff Writer

Michael is a former graphic designer who’s been building and tweaking desktop computers for longer than he cares to admit. His interests include folk music, football, science fiction, and salsa verde, in no particular order.

Read More

Continue Reading

Tech

New Pixel Watch leak reveals watch faces, strap styles and more

Published

on

By

New Pixel Watch leak reveals watch faces, strap styles and more
Google Pixel watch



The Google Pixel Watch is incoming
(Image credit: Google)

We’re expecting the Google Pixel Watch to make its full debut on Thursday, October 6 – alongside the Pixel 7 and the Pixel 7 Pro – but in the meantime a major leak has revealed much more about the upcoming smartwatch.

Seasoned tipster @OnLeaks (opens in new tab) has posted the haul, which shows off some of the color options and band styles that we can look forward to next week. We also get a few shots of the watch interface and a picture of it being synced with a smartphone.

Watch faces are included in the leak too, covering a variety of different approaches to displaying the time – both in analog and digital formats. Another image shows the watch being used to take an ECG reading to assess heartbeat rate.

Just got my hands on a bunch of #Google #PixelWatch promo material showing all color options and Watch Bands for the first time. Some details revealed as well…@Slashleaks 👉🏻 https://t.co/HzbWeGGSKP pic.twitter.com/N0uiKaKXo0October 1, 2022

See more

Full colors

If the leak is accurate, then we’ve got four silicone straps on the way: black, gray, white, and what seems to be a very pale green. Leather straps look to cover black, orange, green and white, while there’s also a fabric option in red, black and green.

We already know that the Pixel Watch is going to work in tandem with the Fitbit app for logging all your vital statistics, and included in the leaked pictures is an image of the Pixel Watch alongside the Fitbit app running on an Android phone.

There’s plenty of material to look through here if you can’t wait until the big day – and we will of course be bringing you all the news and announcements as the Google event unfolds. It gets underway at 7am PT / 10am ET / 3pm BST / 12am AEDT (October 7).


Analysis: a big moment for Google

It’s been a fair while since Google launched itself into a new hardware category, and you could argue that there’s more riding on the Pixel Watch than there is on the Pixel 7 and Pixel 7 Pro – as Google has been making phones for years at this point.

While Wear OS has been around for a considerable amount of time, Google has been leaving it to third-party manufacturers and partners to make the actual hardware. Samsung recently made the switch back to Wear OS for the Galaxy Watch 5 and the Galaxy Watch 5 Pro, for example.

Deciding to go through with its own smartwatch is therefore a big step, and it’s clear that Google is envious of the success of the Apple Watch. It’s the obvious choice for a wearable for anyone who owns an iPhone, and Google will be hoping that Pixel phones and Pixel Watches will have a similar sort of relationship.

What’s intriguing is how Fitbit fits in – the company is now run by Google, but so far we haven’t seen many signs of the Fitbit and the Pixel lines merging, even if the Pixel Watch is going to come with support for the Fitbit app.

Dave is a freelance tech journalist who has been writing about gadgets, apps and the web for more than two decades. Based out of Stockport, England, on TechRadar you’ll find him covering news, features and reviews, particularly for phones, tablets and wearables. Working to ensure our breaking news coverage is the best in the business over weekends, David also has bylines at Gizmodo, T3, PopSci and a few other places besides, as well as being many years editing the likes of PC Explorer and The Hardware Handbook.

Read More

Continue Reading

Trending

Copyright © 2022 Xanatan