text:
Q: XDocReportRegistry.getRegistry() works fine through eclipse, but doesn't work in a third party app I'm using XDocReport to replace the data in placeholders in docx file. This worked fine from eclipse. I exported the App Client Jar file and used it in another third party product. the getRegistry method threw exception with the message:
fr/opensagres/xdocreport/document/registry/XDocReportRegistry
Please help.

A: I placed the XDocReport JARs in the 3rd party app server's common lib directory and it worked fine after restarting the server.

redpajama_set_name: RedPajamaStackExchange


text:
package containerdisk

import (
	"fmt"
	"os"
	"path"
	"path/filepath"
	"strconv"

	"kubevirt.io/client-go/log"

	kubev1 "k8s.io/api/core/v1"
	"k8s.io/apimachinery/pkg/api/resource"

	ephemeraldisk "kubevirt.io/kubevirt/pkg/ephemeral-disk"

	v1 "kubevirt.io/client-go/api/v1"
	diskutils "kubevirt.io/kubevirt/pkg/ephemeral-disk-utils"
	"kubevirt.io/kubevirt/pkg/util"
)

var containerDiskOwner = "qemu"

var podsBaseDir = util.KubeletPodsDir

var mountBaseDir = filepath.Join(util.VirtShareDir, "/container-disks")

type SocketPathGetter func(vmi *v1.VirtualMachineInstance, volumeIndex int) (string, error)
type KernelBootSocketPathGetter func(vmi *v1.VirtualMachineInstance) (string, error)

const KernelBootName = "kernel-boot"
const KernelBootVolumeName = KernelBootName + "-volume"

const ephemeralStorageOverheadSize = "50M"

func GetLegacyVolumeMountDirOnHost(vmi *v1.VirtualMachineInstance) string {
	return filepath.Join(mountBaseDir, string(vmi.UID))
}

func GetVolumeMountDirOnGuest(vmi *v1.VirtualMachineInstance) string {
	return filepath.Join(mountBaseDir, string(vmi.UID))
}

func GetVolumeMountDirOnHost(vmi *v1.VirtualMachineInstance) (string, bool, error) {
	basepath := ""
	foundEntries := 0
	foundBasepath := ""
	for podUID := range vmi.Status.ActivePods {
		basepath = fmt.Sprintf("%s/%s/volumes/kubernetes.io~empty-dir/container-disks", podsBaseDir, string(podUID))
		exists, err := diskutils.FileExists(basepath)
		if err != nil {
			return "", false, err
		} else if exists {
			foundEntries++
			foundBasepath = basepath
		}
	}

	if foundEntries == 1 {
		return foundBasepath, true, nil
	} else if foundEntries > 1 {
		// Don't mount until outdated pod environments are removed
		// otherwise we might stomp on a previous cleanup
		return "", false, fmt.Errorf("Found multiple pods active for vmi %s/%s. Waiting on outdated pod directories to be removed", vmi.Namespace, vmi.Name)
	}
	return "", false, nil
}

func GetDiskTargetDirFromHostView(vmi *v1.VirtualMachineInstance) (string, error) {
	basepath, found, err := GetVolumeMountDirOnHost(vmi)
	if err != nil {
		return "", err
	} else if !found {
		return "", fmt.Errorf("container disk volume for vmi not found")
	}

	return basepath, nil
}

func GetDiskTargetPathFromHostView(vmi *v1.VirtualMachineInstance, volumeIndex int) (string, error) {
	basepath, err := GetDiskTargetDirFromHostView(vmi)
	if err != nil {
		return "", err
	}

	return fmt.Sprintf("%s/disk_%d.img", basepath, volumeIndex), nil
}

func GetDiskTargetPathFromLauncherView(volumeIndex int) string {
	return filepath.Join(mountBaseDir, fmt.Sprintf("disk_%d.img", volumeIndex))
}

func GetKernelBootArtifactPathFromLauncherView(artifact string) string {
	artifactBase := filepath.Base(artifact)
	return filepath.Join(mountBaseDir, KernelBootName, artifactBase)
}

func SetLocalDirectory(dir string) error {
	mountBaseDir = dir
	return os.MkdirAll(dir, 0750)
}

func SetKubeletPodsDirectory(dir string) {
	podsBaseDir = dir
}

// used for testing - we don't want to MkdirAll on a production host mount
func setPodsDirectory(dir string) error {
	podsBaseDir = dir
	return os.MkdirAll(dir, 0750)
}

// The unit test suite uses this function
func setLocalDataOwner(user string) {
	containerDiskOwner = user
}

// GetDiskTargetPartFromLauncherView returns (path to disk image, image type, and error)
func GetDiskTargetPartFromLauncherView(volumeIndex int) (string, error) {

	path := GetDiskTargetPathFromLauncherView(volumeIndex)
	exists, err := diskutils.FileExists(path)
	if err != nil {
		return "", err
	} else if exists {
		return path, nil
	}

	return "", fmt.Errorf("no supported file disk found for volume with index %d", volumeIndex)
}

// NewSocketPathGetter get the socket pat of a containerDisk. For testing a baseDir
// can be provided which can for instance point to /tmp.
func NewSocketPathGetter(baseDir string) SocketPathGetter {
	return func(vmi *v1.VirtualMachineInstance, volumeIndex int) (string, error) {
		for podUID := range vmi.Status.ActivePods {
			basePath := getContainerDiskSocketBasePath(baseDir, string(podUID))
			socketPath := filepath.Join(basePath, fmt.Sprintf("disk_%d.sock", volumeIndex))
			exists, _ := diskutils.FileExists(socketPath)
			if exists {
				return socketPath, nil
			}
		}
		return "", fmt.Errorf("container disk socket path not found for vmi \"%s\"", vmi.Name)
	}
}

// NewKernelBootSocketPathGetter get the socket pat of the kernel-boot containerDisk. For testing a baseDir
// can be provided which can for instance point to /tmp.
func NewKernelBootSocketPathGetter(baseDir string) KernelBootSocketPathGetter {
	return func(vmi *v1.VirtualMachineInstance) (string, error) {
		for podUID := range vmi.Status.ActivePods {
			basePath := getContainerDiskSocketBasePath(baseDir, string(podUID))
			socketPath := filepath.Join(basePath, KernelBootName+".sock")
			exists, _ := diskutils.FileExists(socketPath)
			if exists {
				return socketPath, nil
			}
		}
		return "", fmt.Errorf("kernel boot socket path not found for vmi \"%s\"", vmi.Name)
	}
}

func GetImage(root string, imagePath string) (string, error) {
	fallbackPath := filepath.Join(root, DiskSourceFallbackPath)
	if imagePath != "" {
		imagePath = filepath.Join(root, imagePath)
		if _, err := os.Stat(imagePath); err != nil {
			if os.IsNotExist(err) {
				return "", fmt.Errorf("No image on path %s", imagePath)
			} else {
				return "", fmt.Errorf("Failed to check if an image exists at %s", imagePath)
			}
		}
	} else {
		files, err := os.ReadDir(fallbackPath)
		if err != nil {
			return "", fmt.Errorf("Failed to check %s for disks: %v", fallbackPath, err)
		}
		if len(files) > 1 {
			return "", fmt.Errorf("More than one file found in folder %s, only one disk is allowed", DiskSourceFallbackPath)
		}
		imagePath = filepath.Join(fallbackPath, files[0].Name())
	}
	return imagePath, nil
}

func GenerateInitContainers(vmi *v1.VirtualMachineInstance, podVolumeName string, binVolumeName string) []kubev1.Container {
	return generateContainersHelper(vmi, podVolumeName, binVolumeName, true)
}

func GenerateContainers(vmi *v1.VirtualMachineInstance, podVolumeName string, binVolumeName string) []kubev1.Container {
	return generateContainersHelper(vmi, podVolumeName, binVolumeName, false)
}

func GenerateKernelBootContainer(vmi *v1.VirtualMachineInstance, podVolumeName string, binVolumeName string) *kubev1.Container {
	if !util.HasKernelBootContainerImage(vmi) {
		return nil
	}

	kernelBootContainer := vmi.Spec.Domain.Firmware.KernelBoot.Container

	kernelBootVolume := v1.Volume{
		Name: KernelBootVolumeName,
		VolumeSource: v1.VolumeSource{
			ContainerDisk: &v1.ContainerDiskSource{
				Image:           kernelBootContainer.Image,
				ImagePullSecret: kernelBootContainer.ImagePullSecret,
				Path:            "/",
				ImagePullPolicy: kernelBootContainer.ImagePullPolicy,
			},
		},
	}

	const fakeVolumeIdx = 0 // volume index makes no difference for kernel-boot container
	return generateContainerFromVolume(vmi, podVolumeName, binVolumeName, false, true, &kernelBootVolume, fakeVolumeIdx)
}

// The controller uses this function to generate the container
// specs for hosting the container registry disks.
func generateContainersHelper(vmi *v1.VirtualMachineInstance, podVolumeName string, binVolumeName string, isInit bool) []kubev1.Container {
	var containers []kubev1.Container

	// Make VirtualMachineInstance Image Wrapper Containers
	for index, volume := range vmi.Spec.Volumes {
		if volume.Name == KernelBootVolumeName {
			continue
		}
		if container := generateContainerFromVolume(vmi, podVolumeName, binVolumeName, isInit, false, &volume, index); container != nil {
			containers = append(containers, *container)
		}
	}
	return containers
}

func generateContainerFromVolume(vmi *v1.VirtualMachineInstance, podVolumeName, binVolumeName string, isInit, isKernelBoot bool, volume *v1.Volume, volumeIdx int) *kubev1.Container {
	if volume.ContainerDisk == nil {
		return nil
	}

	volumeMountDir := GetVolumeMountDirOnGuest(vmi)
	diskContainerName := fmt.Sprintf("volume%s", volume.Name)
	diskContainerImage := volume.ContainerDisk.Image
	resources := kubev1.ResourceRequirements{}
	resources.Limits = make(kubev1.ResourceList)
	resources.Requests = make(kubev1.ResourceList)
	resources.Limits[kubev1.ResourceMemory] = resource.MustParse("40M")
	resources.Requests[kubev1.ResourceCPU] = resource.MustParse("10m")
	resources.Requests[kubev1.ResourceEphemeralStorage] = resource.MustParse(ephemeralStorageOverheadSize)

	var mountedDiskName string
	if isKernelBoot {
		mountedDiskName = KernelBootName
	} else {
		mountedDiskName = "disk_" + strconv.Itoa(volumeIdx)
	}

	if vmi.IsCPUDedicated() || vmi.WantsToHaveQOSGuaranteed() {
		resources.Limits[kubev1.ResourceCPU] = resource.MustParse("10m")
		resources.Requests[kubev1.ResourceMemory] = resource.MustParse("40M")
	} else {
		resources.Limits[kubev1.ResourceCPU] = resource.MustParse("100m")
		resources.Requests[kubev1.ResourceMemory] = resource.MustParse("1M")
	}
	var args []string
	var name string
	if isInit {
		name = diskContainerName + "-init"
		args = []string{"--no-op"}
	} else {
		name = diskContainerName
		copyPathArg := path.Join(volumeMountDir, mountedDiskName)
		args = []string{"--copy-path", copyPathArg}

		log.Log.Object(vmi).Infof("arguments for container-disk \"%s\": --copy-path %s", name, copyPathArg)
	}
	container := &kubev1.Container{
		Name:            name,
		Image:           diskContainerImage,
		ImagePullPolicy: volume.ContainerDisk.ImagePullPolicy,
		Command:         []string{"/usr/bin/container-disk"},
		Args:            args,
		VolumeMounts: []kubev1.VolumeMount{
			{
				Name:      podVolumeName,
				MountPath: volumeMountDir,
			},
			{
				Name:      binVolumeName,
				MountPath: "/usr/bin",
			},
		},
		Resources: resources,
	}

	return container
}

func CreateEphemeralImages(vmi *v1.VirtualMachineInstance, diskCreator ephemeraldisk.EphemeralDiskCreatorInterface) error {
	// The domain is setup to use the COW image instead of the base image. What we have
	// to do here is only create the image where the domain expects it (GetDiskTargetPartFromLauncherView)
	// for each disk that requires it.

	for i, volume := range vmi.Spec.Volumes {
		if volume.VolumeSource.ContainerDisk != nil {
			if backingFile, err := GetDiskTargetPartFromLauncherView(i); err != nil {
				return err
			} else if err := diskCreator.CreateBackedImageForVolume(volume, backingFile); err != nil {
				return err
			}
		}
	}

	return nil
}

func getContainerDiskSocketBasePath(baseDir, podUID string) string {
	return fmt.Sprintf("%s/pods/%s/volumes/kubernetes.io~empty-dir/container-disks", baseDir, podUID)
}

redpajama_set_name: RedPajamaGithub


text:
EMOTIONAL TIES: Esther Freud on the therapeutic value of sewing, tranquil places and a rescue dog
Louise Haywood-Schiefer
Our seven-and-a-half-year-old dog Billy came from a Sheffield rescue home. He's been a wonderful addition to the family. It's lovely walking with him in the woods nearby – I've made lot of new friends through him.
When my father Lucian [Freud] died in 2011, I inherited a bundle of his paint brushes. Their oily, turpsy paint smell reminds me of the great sense of discipline and commitment to work he handed down to me. He had the most incredible sense of fun, joy and delight in life, something I miss every day.
Becoming a writer was a dream beyond all expectations but Jean Rhys's 1930's novel Voyage in the Dark, bought at Greenwich Market in the mid 80's, inspired me to try. It was so soulfully, wittily written.
My daughter Anna, 20, has always been very creative. She made this card for me one Mother's day, a humorous reminder that she likes to think she is my most important child.
A A Gill designed this Prison Calendar cushion with the charity Fine Cell work, which teaches needlework to prisoners. My new play Stitchers was inspired by his expression 'hard men, soft furnishings'. For 20 years I've visited a prison's sewing class – it's deeply therapeutic for all involved.
This was a birthday present given to me in Morocco and it's been my treasure box of precious things ever since: baby hospital anklets, a photo of me as a punky teen, a rosary from my grandmother, a baby tooth from one of the children, and a patch by my mother's then boyfriend Bilal of a bird perched on a flower.
I'm about five in this rare photograph from my peripatetic childhood in Morocco with our mother. When I wrote [my first novel] Hideous Kinky, the way my eyes are looking up helped me to visualise my character. My father drew the book's cover from this photo.
When I was small, playing with my mother Bernardine [Coverley's] Moroccan button box was a great source of pleasure. She was always making things, something I've inherited from her. I like to sew and mend.
This candle is by my fashion designer sister Bella, two years older than me and one of my greatest allies. It's a rare day when we don't speak. It reminds me how proud I am of her – so inventive, imaginative, stylish and energised, and a great businesswoman, too.
This photograph of my sons, Albie [left] and Gene, now 23 and 13, was taken when Gene was a toddler. They couldn't be more different – Albie loves football; Gene is gentle, quiet and musical. Motherhood has brought me an unexpected confidence and the freedom not to have to think about myself all the time.
My husband [actor David Morrissey] took this photograph on our first trip together to Suffolk, near to where my paternal grandparents had lived in the 1930's. It sums up the peace and tranquility the area holds for me.
Esther's play Stitchers will be at the Jermyn Street Theatre, London SW1 from 30 May to 23 June; jermynstreettheatre.co.uk
Interview by Fiona McCarthy
Previous articleMoroccan mint tea chocolate pots
Next article20 years of nursing: What it's really like to be on the frontline of life and death
Jessica Lawrence
Jennifer Saunders, seriously: How the queen of comedy is reinventing herself at 61
Vigil: The gripping new BBC thriller starring Suranne Jones
The Serpent: The first look at Netflix at the BBC's new drama starring Jenna Coleman
Popular in Celebrity
Lucy Boynton on new Netflix drama Gypsy and an A-list Agatha...
Actress Phyllida Law on tying the knot with the Magic Roundabout...
Georgina Castle is a real Super Trouper in the West End's...
Liz Jones on falling for Meghan Markle
Strictly favourite Debbie McGee on why 'it's attitude, not age that...
QUICKFIRE: TV's Supervet Noel Fitzpatrick on strange cures, royal mishaps and...
EMOTIONAL TIES: Sophie Ellis-Bextor on her freakily favourite things
QUICKFIRE: Impressionist Jon Culshaw on big hair days, being late and...
WHEN I WAS… Queen for a day
EMOTIONAL TIES: Olly Murs reveals the stories behind his favourite things

redpajama_set_name: RedPajamaCommonCrawl


Tommy's is a charity which funds research into pregnancy-related problems, health and treatments and also provides medical professionals, parents and parents-to-be with information about pregnancy health issues.
Sharon is chairperson of the Yorkshire Branch of Tommy's and recently put on an 80s-themed dinner dance night.
She described the experience of organising the event: "It hasn't been too bad really as there were three of us to take a part each and as we had done similar events before we were able to tap into existing resources and information to help us. For example we updated the ticket and flyer template, all committee members sold tickets with me and helped with table planning and negotiating with the venue and entertainment. I kept an eye on the costs and overheads and wrote off for raffle prizes and collated a list of the prizes we had."
Sharon told us how she sourced acts and arranged a venue: "Again we were able to tap into existing resources which we have previously used. The first time round we just asked friends and family for names of acts they had seen/used/enjoyed and wrote to them all and asked for a reduced rate - we now have a few who just charge expenses which is great and means more goes to Tommy's. With regard to a venue we picked a central location - we had used the venue before and so were familiar with the events organiser and company. They were very willing to help and ensured we had tables, chairs, dance floor etc and also that we had designated areas for the food service, raffle tables and auction items.
Although the event was a huge success – raising over £2,000 - it wasn't all plain sailing. Sharon explained: "It can be time-consuming particularly in the final two weeks prior to the event with collating monies, purchasing last-minute items for decorating the room (we do this ourselves to keep overheads down), typing up programmes for the evening and sorting out the raffle. We often feel uncomfortable asking for raffle prizes but this year we were given an enabling grant of £400 by a company called Steria which was a really big help and covered costs such as an LCD TV for the raffle, helium and balloons, and wine packages for prizes.
Be realistic about what is achievable with the time and help you have.
Research your idea for an event to gauge interest and also an acceptable ticket price. To help keep costs down have a go at designing your own tickets - most people want the money to go to the charity and not on expensive printed tickets that end up in the bin.
Try to offer value for money for your guests, but ensure your ticket prices cover the overheads. That way any raffle or auction you have will ensure that you make something for your charity.
Don't be shy about asking for prizes and donations - most companies and supermarkets have a charitable fund to donate a prize.
Also don't be shy to ask for a free or heavily discounted venue - they make lots of money at the bar...!
If you are fundraising for a larger charity, write to them and ask for leaflets to give out on the night. They may also have balloons and goods for you to use to decorate the venue, and able to give help with a press release to advertise your event.


There was already a mounted tmpfs, but the directory /dev/shm was not writeable for user nobody.
This entry was posted on Wednesday, May 29th, 2013 at 2:47 pm and is filed under Software Development. You can follow any responses to this entry through the RSS 2.0 feed.Both comments and pings are currently closed.


text: The 3d Java Rigid Body Physics Simulation, using Java OpenGL


text:
2012 Doomsday (2008) Full Movie Online
On December 21, 2012 four strangers on a journey of faith are drawn to an ancient temple in the heart of Mexico. For the Mayans it is the last recorded day. For NASA scientists it is a cataclysmic polar shift. For the rest of us, it is Doomsday.
Genre: Adventure, Fantasy, Horror
Director: Nick Everhart
Actors: Ami Dolenz, Cliff De Young, Dale Midkiff, Danae Nason
Keywords:USA
The Shadow Riders (1982)
After the Civil War, two brothers demobilized from the army return home and must rescue certain relatives who have been kidnapped by a band of renegade Confederates.
Genre: Action, Adventure, TV Movie, Western
Pacific Rim: Uprising (2018)
Jake Pentecost, son of Stacker Pentecost, reunites with Mako Mori to lead a new generation of Jaeger pilots, including rival Lambert and 15-year-old hacker Amara, against a new Kaiju threat.
Country: China,USA
Veer (2010)
A Pindari Prince goes to England to study military tactics so that he can avenge his people, but while there, he falls in love.
Genre: Action, Adventure, Romance
Bee Movie (2007) Full Movie Online
Barry B. Benson, a bee just graduated from college, is disillusioned at his lone career choice: making honey. On a special trip outside the hive, Barry's life is saved by…
Pan (2015) Full Movie Online
12-year-old orphan Peter is spirited away to the magical world of Neverland, where he finds both fun and danger, and ultimately discovers his destiny — to become the hero who…
Genre: Adventure, Family, Fantasy
Pirates of the Caribbean: On Stranger Tides (2011) Full Movie Online
Jack Sparrow and Barbossa embark on a quest to find the elusive fountain of youth, only to discover that Blackbeard and his daughter are after it too.
Red Scorpion (1988)
A Soviet Special Forces soldier is sent on a mission to infiltrate an African rebel army and assassinate its leader, but the war machine they trained starts to think for…
Country: Namibia,South Africa,USA
Genre: Action, Adventure, War
The BFG (2016) Full Movie Online
A girl named Sophie encounters the Big Friendly Giant who, despite his intimidating appearance, turns out to be a kind-hearted soul who is considered an outcast by the other giants…
Country: Canada,UK,USA
National Lampoon's Vacation (1983) Full Movie Online
The Griswold family's cross-country drive to the Walley World theme park proves to be much more arduous than they ever anticipated.
Destined to Ride (2018)
Lily's life is turned upside down when she is forced to leave her friends to spend the summer on a remote ranch with her nature-loving aunt. Convinced her social life…
Nazis at the Center of the Earth (2012) Full Movie Online
Researchers in Antarctica are abducted by a team of masked storm troopers. They are dragged deep underground to a hidden continent in the center of the earth. Here Nazi survivors,…


text:
Q: ocaml in function type how to use match with? I need to solve this. Write a function (type 'a listl = Empty | Cons of 'a listl * 'a) list.
I have never used match with without list.
It is very confusing to use match with as an integer.
type 'a listl = Empty | Cons of 'a listl * 'a

var: int -> (int -> 'a) ->'a listl

tabu 5 (fun x -> x^x) => [0;1;9;16;25]

Such results must come out.
type 'a listl = Empty | Cons of 'a listl * 'a

let rec tabu n f =
match n with
| 0 ->
| n -> if n > 0 then f n :: (tabu (n-1) f) else Empty
;;

In match with, how to use "0,n" instead of "Empty,Cons"?
Is there any good idea?

A: If I understand correctly, you are asking how to match values of type int. If you want to distinguish whether your parameter n has the value 0 or some other value, you can do it like so:
match n with
| 0 -> ...
| _ -> ...

where the underscore is an anonymous wildcard pattern that matches any value. (But in this match it will not match 0 because the first pattern takes precedence.) In this case you could achieve the same thing with an if like so:
if n=0
then ...
else ...

If you want to compare n with something that is not a constant, say m, then you cannot do just
match n with
| m -> ...

because that does not use m as its original binding. Instead it treats m as a non-anonymous wildcard pattern and introduces a new binding for m with the value of n in the expression following the pattern. So you have to do
if n=m
then ...
else ...

or use a when clause like so:
match n with
| _ when n=m ->


text:
\section{Introduction}

The OS movement allows any developer to read or attempt to contribute to the source code hosted in a publicly accessible location, such as GitHub. This trend may have several advantages, such as code reviewers catching software bugs promptly. Furthermore, the creativity behind a software's design is no longer limited to a team of developers as anyone is free to propose their ideas. This advantage allows additional features or functionalities to be implemented, thus possibly making the project the market leader in its area.

Although several advantages are present with the OS movement, there are also disadvantages. One possible disadvantage is that certain individuals in public may have malicious intentions, and the publicly accessible code may raise security concerns. A team of founders of the OS platform may review every pull request to ensure the benign intentions of the commits. However, some environments are known to lack control measures. Some of these environments may include public registries, which are public repositories anyone can upload their packages to for others to use. These repositories intend to serve as collections of libraries to facilitate development tasks with readily available packages. Some public registries do not have any control measurements besides reporting the malicious code once detected by a developer. This issue gives the attacker a certain lifespan to perform malicious activities.

PyPi and npm are two popular public registries. These environments require developers to verify their email addresses without further control, making it much easier for attackers to create malicious accounts. These accounts can publish any package in their public registry, amplifying an attack's impact naturally. Furthermore, attackers can take advantage of several other techniques that benefit from human errors. Some of these techniques are typosquatting and combosquatting. When an attacker intentionally publishes a package in the public registry with a similar name to popular packages, these techniques benefit from a potential typo during the manual installation of dependencies \cite{vu2020typosquatting}. Typosquatting takes advantage of typos during the installation of packages, while combosquatting hopes to exploit a mistake of the order in the package name, where the name consists of multiple nouns, such as "python-nmap" typed as "nmap-python" \cite{vu2020typosquatting}. The ultimate goal in both attacks is to get the developer to install the malicious package.

Another popular attack surface for these registries is the interdependent nature of its packaging environment. A handful of accounts maintain numerous packages. These packages are dependent on several other libraries. Compromising these accounts would give an attacker the ability to modify the code at will. Furthermore, if there is a vulnerability in one of the popular packages, then the issue will propagate through all the other libraries that depend on it. This concept is also known as software supply-chain security, which refers to outsiders accessing the final project \cite{ellison2010evaluating,ohm2020backstabber}. Software supply-chain security is another research field but seems to be heavily related to OS registry security. There has already been a study on software supply-chain and typosquatting attacks on public registries that includes npm and PyPi; however, the study did not cover other common dangers in the OS registries such as trivial packages \cite{duan2021towards}.

Another attack surface in the OS settings is the technical lag, which is the time or version difference between the dependency used in production and the most recent version available for installation \cite{zerouali2019impact}. For instance, when package A depends on several other libraries in production that are not up to their latest versions, known vulnerabilities may compromise package A as well through these dependencies. npm does not seem to help developers keep up with the latest versions of their libraries, as package.json requires developers to use a specific version or range of versions of a package instead of automatically choosing the most recent version \cite{zimmermann2019small}.

We are the first to present a systematic survey of public registries' common vulnerabilities. In this paper, we will be exploring the impact of each vulnerability. We will be suggesting untested risk mitigation strategies we compiled from the literature to the administrators of the mentioned OS registries. We specifically incorporated ML techniques into our risk mitigation strategies to make our solutions more adaptable to different types of future attacks. We made this assumption as the features of ML-based tools can be changed to modify the program's purpose.

To the best of our knowledge, our work is the first in the field to offer countermeasures against the security problems in npm and PyPi environments. We have not conducted physical experiments or surveyed developers, as we merely focused on presenting the state of the field. We outlined our main contributions to the field:
\begin{itemize}
\item Compilation of all the threats and vulnerabilities from the literature that exists in public registries.
\item Compilation of work that explains the prevalence of the presented risks in popular OS environments.
\item Countermeasure suggestions against the mentioned attack surfaces.
\end{itemize}
Similar work has been published previously, such as the study from Vaidya et al. in 2019. The paper indeed built a systematic threat model in OS environments and provided threat classifications. Nevertheless, we determined that this study did not provide sufficient coverage as certain issues, such as trivial packages, were not discussed.

The OS movement has brought several advantages, and we would like to support the safety of its members. Supporting the public registry safety will also benefit the OS community as it would draw some companies, which could not enter the environment due to their high-security requirements. This paper aims to disclose the security issues in public registries to contribute to the OS community. This project's scope does not extend to vulnerabilities in native code or compiler as we focus more on software reuse.

\section{Background}

It would be beneficial to explain a couple of frequently used terms in this paper that relate to the interdependent structure of libraries.

\subsection{Dependencies and Dependency Trees}
Dependencies, packages, or libraries are fairly similar terms in the context of our survey. Dependencies are readily available code for developers to use in their projects to accelerate the speed of the implementation phase. Private companies may create these dependencies, or they may even be OS. The implementation in these libraries is usually not individually scrutinized for efficiency purposes in a project's life cycle.

A dependency tree visualizes the direct relationship between libraries. The simplest tree structure would be that package A depends on package B, meaning that package A uses components, functions, or code snippets from package B. These relationships can extend to several packages vertically, introducing more attack surfaces for a specific dependency.

\subsection{Package Manager}
Package managers allow developers to manage their dependencies in a central document, for example, a JSON file. The managers facilitate the installation and sharing of dependencies as the developer no longer has to visit the library's official website to download the package into his local repository \cite{duan2020measuring}. The central document has a list of the dependencies. It is already connected to a registry that contains all the libraries needed via software. These managers are also configurable to connect to private registries, where all the libraries are internal to a company. Recent studies have shown that package managers have been abused to distribute malware, thus making them a trade-off between convenience and security \cite{duan2020measuring}. \cite{vaidya2019security}.

\subsection{Software Supply-Chain Attacks}

The goal of supply-chain attacks is to inject malicious code into software or library externally. These attacks modify the targeted program so that it is still validly signed by its owner. The attacker simply injects his code into one of the software's dependencies \cite{ohm2020backstabber}. Theoretically, an attacker can do this injection in any given node in the software's dependency tree. The ultimate goal is to alter the behavior of the root or a specific node, which is the targeted software product, using a child node, which in this case is a dependency node in the tree \cite{ohm2020backstabber}.

\subsection{Typosquatting and Combosquatting}

Typosquatting is an attack methodology where an attacker intentionally publishes a package with a typo in its name, making the name relatively close to a popular package's name. The attacker hopes that a victim would make a typo while downloading dependencies. Thus, the victim would download the malicious package instead of the intended one. One example of this type of attack is the popular \textit{lodash} package incident, where it had a typosquatting package named \textit{loadsh}. In the English language, a developer might likely download the \textit{loadsh} package after making a typo.

Combosquatting is similar to typosquatting; however, some packages consist of multiple words in their name. Sometimes, it would be easy to forget the order of the words, and the attacker intentionally creates a package that contains the same words as the targeted package, but the order of the words will vary. The goal is similar to typosquatting, benefiting from an innocent mistake of a developer. A researcher uploaded typosquatting packages to different repositories, including PyPi, and the package received around 45K downloads over several months \cite{vu2020typosquatting}.

\subsection{Machine Learning}

Learning is considered the hallmark of human intelligence, and researchers have worked on making machines intelligent, giving birth to ML \cite{wang2009brief}. It is the study of methods to allow computers to gain new knowledge and constantly improve themselves \cite{wang2009brief}. The definition can also be the process that allows computers to convert data to knowledge through certain techniques \cite{wang2009brief}. The applications of the ML techniques have been quite popular in recent years, and one of these applications is the area of information security. We will incorporate some ML techniques  into our proposed security remedies to provide a more reliable method of identifying and preventing malicious actors.

\section{Motivation}

Although several studies exist in the field of OS registry and software supply chain security, there has not been a known source to publish a survey-structured paper to construct a centralized information bank on the types of dangers in OS registries. Furthermore, we have not found a project to offer mitigation strategies against these attacks. The feasibility of our solutions may be unclear, as we have not tested any of them. However, we hope they would serve as a first step to develop more systematic countermeasures.

OS registry security is a relatively generic field that tackles certain security issues in OS environments. It quite surprised us that a survey does not yet exist on the security of the public library registries. Therefore, to contribute to the field and give a glimpse of the area's current state, this work has been thought to be useful. We hope to enhance the information security field by offering risk mitigation strategies and serving as a first step to build a novel chapter in its curriculum. We expect to have several corrections done on this draft of a chapter. Still, our ultimate motivation is to foster interest in the field and raise awareness against these issues as we also support the OS community.

\section{General Overview of Vulnerabilities in npm and PyPi}

Although several other package managers and OS environments exist, we decided to focus on PyPi and npm as they contain the most libraries in their registries. Similar ecosystems and their size comparisons are illustrated in figure \ref{size-comparision} \cite{vaidya2019security}.

\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{Images/size-comparisions.png}
  \caption{A size comparison in package management ecosystems \cite{vaidya2019security}}
  \label{size-comparision}
\end{figure}

To understand the scope of the security issue and get an estimation of the number of vulnerable packets, we scanned research papers. We found that one of the projects in our references compiled a summary of 700 security reports gathered from Snyk.io published before 2017-11-09 in figure \ref{vulnerability-table} \cite{decan2018impact}. However, researchers removed certain issues, such as typosquatting, as they do not introduce vulnerabilities in existing packages \cite{decan2018impact}. Among the 610K packages, 133602 packages directly depend on vulnerable packages, and 52\% of these packages, which is 72470 in total, have at least one release that relies on a vulnerable version \cite{decan2018impact}.

\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{Images/vulnerability-comparision.png}
  \caption{A summary of the npm dataset \cite{decan2018impact}}
  \label{vulnerability-table}
\end{figure}

The median number of releases affected by a high-severity vulnerable package is 26 in the npm environment \cite{decan2018impact}. The encouragement from the npm and PyPi environment to reuse code seems to accelerate this issue \cite{vaidya2019security}.

\subsection{Direct, Indirect Dependencies, and Heavy Code Reuse}

As stated before, code reuse is common in the npm environment. Projects are either directly or indirectly dependent on each other, meaning that project A that uses code from project B has a direct dependency relationship as A directly depends on B. If B depends on project C, then A has an indirect dependency on C, increasing the attack surface. Indirect dependencies are also referred to as "transitive dependencies" as some of the work in the literature uses that term to build their graphs, such as figure \ref{dependency-growth} that indicates the average number of dependencies projects use over time.

\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{Images/dependency-growth-over-time.PNG}
  \caption{The growth of both types of dependencies over time in logarithmic scale \cite{zimmermann2019small}}
  \label{dependency-growth}
\end{figure}

Figure \ref{dependency-growth} implies that a developer implicitly trusts around 80 other packages by using a library \cite{zimmermann2019small}. This trust also means that a hacker's attack surface includes the accounts that maintain the indirectly dependent packages.

Another term based on transitive dependency is the "Package Reach," which refers to the number of transitive dependencies a specific library has \cite{zimmermann2019small}. It has been stated that some popular packages have a package reach of over 100000, drastically increasing the attack surface, and this trend has been observed to be increasing \cite{zimmermann2019small}. The package reach also increases the size of the dependency graph. If one of the dependent packages is compromised by either a squatting attack or a stolen credentials of a maintainer account, it would be reasonable to assume that a security risk would arise. The average package reach for a single given library seems to be in an increasing trend for the last couple of years, according to figure \ref{average-package-reach}.

\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{Images/average-package-reach.PNG}
  \caption{The average package reach overtime in the npm environment \cite{zimmermann2019small}}
  \label{average-package-reach}
\end{figure}

Once the attacker injects his code into a dependency graph, he can execute it in various phases. The attack tree that outlines wherein an attacker can execute the malicious script is also illustrated in figure \ref{attack-tree}.

\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{Images/attack-tree.PNG}
  \caption{The attack tree that outlines the possible phases a malicious script can be executed \cite{ohm2020backstabber}}.
  \label{attack-tree}
\end{figure}

Zimmerman's 2019 USENIX paper seems to be a leading study examining the interdependent structure of packages and their trends in the npm environment. However, it has also been determined that most papers in this field seem to be less than five years. This finding implies that security experts recently started to investigate the interdependent packaging structure of OS environments. Software supply-chain attacks, on the other hand, seemed to be a more mature field.

\subsection{Technical Lag}

Packages relying on vulnerable libraries is not the only issue, as Gonzalez-Barahona et al. introduced the concept of technical lag, which is "the increasing lag between upstream development and the deployed system if no corrective actions are taken" \cite{gonzalez2017technical,zerouali2019formal}. It is essentially the phenomenon where a package lags behind its most recent release \cite{decan2018evolution}. Code reuse only seems to be contributing to the issue as most recent packages can still be outdated if they rely on unpatched components \cite{zerouali2019formal}.

One may reasonably want the package updates to be automated to solve the issue. Package updates may introduce incompatibility issues with the existing project \cite{zerouali2019formal}. Developers should not ignore patches as well due to known vulnerabilities. Patches also introduce new functionalities that a project misses by avoiding incompatibility risks, causing a concept named "technical debt" to arise \cite{gonzalez2017technical}. However, the issue mainly seems to be a trade-off between security and functionality.

The perspective against technical lag also seems to vary as the literature contains data implying that clients can be safe from technical lag. It has been concluded that one in four dependencies and two in five releases suffer technical lag in the npm environment \cite{decan2018evolution}. After 2015, it has also been observed that the average duration of technical lag in npm was 7 to 9 months, meaning that a specific dependency would be updated 7 to 9 months after a library's new release \cite{decan2018evolution}.

Furthermore, benign users might not be the ones to discover a vulnerability first. Most vulnerabilities take a long time to be discovered, especially low-severity ones \cite{decan2018impact}. Although project contributors fix most vulnerabilities discovered in the source code in a short amount of time, a non-negligent portion takes longer \cite{decan2018impact}.

To counter the dangers of the technical lag argument, we found one report stating that 73.3\% of outdated clients were safe from threats as these clients did not use the specific vulnerable code \cite{zapata2018towards}. A vulnerability tends to be in a specific function, and not every client will have to use that particular function. However, the risk of a client using the vulnerable function persists. Developers who realize the functions they are using are not particularly affected by the stated issue take longer to update their dependencies, increasing the technical lag \cite{zapata2018towards}.

In addition, One may reasonably conclude that the older the package is, the less vulnerability it will have. Thus, a possible solution may be to use old packages. However, a study in the literature has found that this claim is wrong as they found that most vulnerabilities are in packages older than 28 months \cite{decan2018impact}. Older packages tend to have more severe vulnerabilities \cite{decan2018impact}. We could not establish a relationship between security and the package's age in this study.

\subsection{Squatting Attacks}

We found that attackers mainly use two methods to spread malicious code in these environments: stealing the credentials of accounts that maintain certain packages to inject their code into the project and tricking users into downloading their packages by methods such as squatting attacks \cite{vu2020typosquatting}. The term squatting attack is an umbrella concept used in this paper to represent typosquatting and combosquatting. We will discuss other types of attack methods against the public registries in this paper, but we focus on these two scenarios in this section. In the first scenario, the "ssh-decorate" package was affected as the attackers took control of the maintainer account and injected code into the package. The injected code would send users' ssh credentials to an attacker-controlled remote server \cite{vu2020typosquatting}. Some popular maintainers can contribute to hundreds of packages, making their accounts critical to a potential compromise \cite{zimmermann2019small}.

In the latter scenario, attackers can fork an existing package and modify the \textit{setup.py} file to download the malicious dependencies in PyPi \cite{vu2020typosquatting}. In addition, an attacker can even use an existing package name after a popular package has been withdrawn by the maintainer from the registry, introducing further attack surfaces \cite{ohm2020backstabber}. One such attack had happened in the past with the go-bindata package when its owner deleted the unmaintained package {vaidya2019security}. Fortunately, the attack was discovered on the same day \cite{vaidya2019security}. Squatting attacks are a problem in the OS registry environment because the repositories allow users to upload code as users are given equal trust initially \cite{taylor2020spellbound}.

Squatting attacks are both dangerous for the developer, stakeholders, and the client as a Trojan virus may be embedded that activates when the project is run \cite{taylor2020spellbound}. Certain code runs on users' machines when npm or PyPi installs packages on the local repository. Thus a client does not even have to use the dependency to be attacked. Some packages are even known to open reverse shells with user privileges using the installation scripts of the packages \cite{taylor2020spellbound}. Manual squatting detection proves to be challenging as some of the name changes are quite hard to notice, as illustrated in table  \ref{malicious-package-samples} that shows some past attacks \cite{taylor2020spellbound}.

\begin{table*}[t]
\centering
\begin{tabular}{ | c | c | c | }
  \hline
 Malicious Package & Legitimate package & Names change \\
 \hline\hline
 virtualnv & virtualenv & Delete 'e' \\
   \hline
 mumpy & numpy & Substitute 'n' by 'm' \\
   \hline
 django-server & django-server-guardian-api & Delete "-guardian-api" \\
 \hline
  urlib3 & urllib3 & Delete 'l' \\
 \hline
   python-mysql & MySQL-python & Swap "python" and "mysql" \\
 \hline
    python-openssl & openssl-python & Swap "openssl" and "python"  \\
 \hline
\end{tabular}
\
   \caption{Some of the samples of squatting attacks selected from the literature in the PyPi environment \cite{vu2020typosquatting}}
  \label{malicious-package-samples}
\end{table*}

The dangers of a typosquatting attack come from the fact that the client is not affected by the malicious activity only but all the other libraries that depend on it, meaning that a developer does not have to make a typo mistake \cite{taylor2020spellbound}. Another challenge in catching these attacks is that not all typosquatting packages are malicious, as the \textit{loadsh} example did not have any harmful content \cite{taylor2020spellbound}. However, it was a copy of an older version of the original \textit{lodash}, meaning that public unpatched vulnerabilities still may be a security concern, as it has been reported that 63 other packages depended on \textit{loadsh} \cite{taylor2020spellbound}.

\subsection{Maintainers and Collaborators}

There is a distinction between maintainers and collaborators in OS environments. Maintainers review and approve contributions while contributors propose code changes \cite{ohm2020backstabber}. Both of these accounts are critical for a secure project. An attacker's goal is to inject malicious code into the dependency tree to affect the targeted software. An attacker can reach that goal by either creating a new package via squatting or using the existing packages that already have users \cite{ohm2020backstabber}. If a maintainer account is compromised, an attacker can easily inject his code. Another possible scenario is that an attacker can pose as a benign contributor and make pull requests with a seemingly useful feature, such as the incident of the unmaintained "event-stream" package that will be mentioned in the following sections \cite{ohm2020backstabber,vaidya2019security}. Embedded inside the feature can be malicious content that may be hard to notice, and considering that a human is reviewing the request, human error can allow the request to be approved. Alternatively, a maintainer account with weak credentials can always be compromised to approve malicious pull requests, or attackers can use social engineering strategies to perform the injection.

The trend presented in the transitive dependency structure is not the only alarming graph. The rise of npm would be from new developers joining the system mainly; however, the package per maintainer has also increased as current members publish new projects \cite{zimmermann2019small}. Each account is becoming responsible for more packages, making it more critical to secure accounts. The average package count per maintainer account seems to be 2.5 in 2012, ascending to 3.5 in 2013 and almost 4.5 in 2018 \cite{zimmermann2019small}. This increase happened for both average and especially for influential maintainers in npm, as the case for some selected popular maintainer usernames can be observed in figure \ref{package-count-per-popular-maintainer} \cite{zimmermann2019small}.

\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{Images/package-count-per-popular-maintainer.PNG}
  \caption{Package count per popular username in npm \cite{zimmermann2019small}}
  \label{package-count-per-popular-maintainer}
\end{figure}

\subsection{Trivial Packages or Micropackages}

Trivial packages are small libraries, which a study in the literature found to be less than 35 lines of code, according to 79\% of their participants who attempted to classify libraries as trivial \cite{abdalkareem2020impact}. Developers have considered trivial packages good until recent trends pushed code reuse to an extreme \cite{abdalkareem2020impact}. The breakdown of popular web services, such as Facebook, Airbnb, and Netflix in 2016 from a Node.js 11-line trivial package named left-pad, only made the concept be questioned further \cite{abdalkareem2017developers,chen2021helping}.

The incident has been referred to as the case that "almost broke the Internet," which led to many discussions over code reuse sparked by David Haney's blog post "Have We Forgotten How to Program?" \cite{abdalkareem2017developers}. Node.js used to allow developers to unpublish projects that lead to the left-pad incident emerge \cite{abdalkareem2017developers}. Although the origin of the incident is not related to a vulnerability in the package itself, it has raised awareness about trivial packages \cite{abdalkareem2017developers}. Numerous developers agreed with Haney's opinion that developers should implement trivial tasks themselves rather than adding an extra dependency to the project \cite{abdalkareem2017developers}. Since then,  people have been working to investigate this issue.

A study has researched the developers' perspectives of trivial packages or micropackages, and the interviewed developers stated that their definition of micropackage is the same across PyPi and npm \cite{abdalkareem2020impact}. It has been found that 16\% of packages in the npm and 10.5\% of packages in PyPi are trivial packages \cite{abdalkareem2020impact}. The same study also questioned developers to understand the reasons for using such packages. It has been found that developers use these packages due to their belief that the packages are well tested and maintained \cite{abdalkareem2020impact}. Developers stated that they use these packages to increase their productivity \cite{abdalkareem2017developers}. The surveyed software developers also stated that they use trivial packages as they do not want to be concerned with extra indirect dependencies. However, it has also been found that trivial packages do use dependencies in some cases \cite{abdalkareem2020impact}. A study has found that 43.7\% of trivial packages have at least one dependency, and 11.5\% have more than 20 dependencies \cite{abdalkareem2017developers}. The surveyed developers also thought that trivial packages create a dependency mess, which is hard to update and maintain \cite{abdalkareem2017developers}. The perspective against trivial packages seems to be controversial, as it has been found that 23.9\% of the JavaScript developers consider them bad. In comparison, 57.9\% of the developers do not consider them to be a bad practice \cite{abdalkareem2017developers}. 70.3\% of the Python developers consider trivial packages as bad practice \cite{abdalkareem2020impact}.

Zimmermann's paper coins this issue as "micropackages" instead of using the term "trivial package." Still, the concepts are the same: packages with fewer lines of source code than a threshold, although this threshold seems ambiguous across the literature \cite{zimmermann2019small}. The specific study explicitly stated that micropackages are insecure as it increases the attack surface and the number of dependencies a project has \cite{zimmermann2019small}.

\subsection{PyPi Overview}

PyPi has limited automated review tools for the uploading process as the npm environment does, making it vulnerable to different kinds of attacks, such as squatting \cite{vu2020typosquatting}. Furthermore, the moderator and administrator team, who has permission to remove packages from the registry, seems to be less than ten people, limiting the maximum number of code reviews they can conduct \cite{vu2020typosquatting}. Considering the 400K package owner, each administrator seems to be responsible for 40K people, assuming every administrator performs code review for malicious content, thus providing a lower bound for the number of package owners per moderator ratio. PyPi allows end-users to report malicious packages. Nevertheless, considering each moderator being responsible for at least 40K developers, it would be only reasonable to question the efficiency of the code reviews. When users download packages using the \textit{pip}, there is no available system that reviews the code to determine its safety aside from a user's antivirus. So, we can outline the process of publishing packages with figure \ref{pypi-ecosystem} that illustrates a high-level view of the schematics of the PyPi ecosystem.

\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{Images/pypi-ecosystem.PNG}
  \caption{An overview of the roles in the PyPi ecosystem \cite{vu2020typosquatting}}
  \label{pypi-ecosystem}
\end{figure}
Spreading malicious code in the wild PyPi is fairly similar to the process we illustrated in the npm environment. Mainly, an attacker can either steal the credentials of an existing account to exploit the current reputation of the project or create a new package by forking the targeted package and modifying the content, or simply creating a brand new package \cite{vu2020typosquatting}. The latter method can still trick users into downloading the attacker's library by a squatting method.

\subsection{Noteworthy Incidents}

Although we described the attack types, we have not given detailed concrete examples until this point. Thus, it would be fruitful for the reader to illustrate these concepts with real-life scenarios.

In July 2018, an attacker stole the credentials of a developer account of a package. The attacker published a malicious version of the \textit{eslint-npm} package that would, during installation, send users' npmjs.org credentials from the .npmrc file to an attacker-controlled server\cite{vaidya2019security}. Although the attack was detected the same day, it has been estimated that 4,500 accounts may have been compromised \cite{vaidya2019security}. This incident clearly shows the importance of the period until an attacker is detected.

A known typosquatting attack happened in July 2017 when a user named "HackTask" uploaded 40 malicious packages to the npm registry with similar names to popular packages. The packages had payloads in their installation script that would ex-filtrate local environment variables, storing sensitive authentication tokens, to the attacker's server \cite{vaidya2019security}. The attack was discovered after 12 days, and it has been estimated that 50 users downloaded the attacker's packages \cite{vaidya2019security}.

Another typosquatting attack happened in the PyPi public registry, where a malicious package, named \textit{jeIlyfish}, hoped to imitate the popular package \textit{jellyfish} by changing the first L of jellyfish to an I, and it stole ssh and GPG keys \cite{vu2020towards}. The malicious package existed in the repository for a year until it was discovered, thus implying that squatting attacks do not necessarily get discovered in a short period \cite{vu2020towards}. One study, which also expressed that vulnerability detection and prevention are insufficient in PyPi, found that the median time a vulnerability is hidden in the PyPi environment is three years regardless of their severity\cite{alfadel2021empirical}. Once the vulnerability is discovered, on median, all packages take four months to have their vulnerability patched, giving plenty of time for an attacker to exploit a zero-day vulnerability \cite{alfadel2021empirical}.

A social engineering technique was also used to attack the npm ``copay" package, and the incident dates back to July 2018, when the attacker emailed the maintainer to offer help with the popular but unmaintained "event-stream" package that copay has an indirect dependency on \cite{vaidya2019security}. Once the attacker gained access to contribute, the attacker injected a malicious dependency into an external package, ``flatmap-stream," of event-stream that would ex-filtrate sensitive wallet information of the copay users to the attacker's server \cite{vaidya2019security}.

All in all, there have been several examples of attacks in npm and PyPi. The interdependent structure of both environments raises software supply-chain security as a concern. It is not only npm and PyPi that gets targeted but other popular package manager software that we have not covered in this survey. One such example is the popular \textit{rest-client package} from the RubyGems registry. attackers used it to insert a Remote-Code-Execution backdoor on web servers \cite{duan2020measuring}. A study in the literature stated that the number of these attacks increases \cite{vu2020towards,alfadel2021empirical}. Therefore, we expect to see additional incidents in the field if admins do not implement countermeasures.

\section{Discussion}

This research focused on presenting the costs of using OS registries to benefit from the readily available libraries other developers have created. These costs mainly originate from security concerns that may damage institutions' IT infrastructure. Evidence has been gathered from the literature to study the main threats in the npm environment comprehensively. No further experiments or studies have been done in this work, as we solely focused on compiling recent work in OS registry security. We determined that the OS environment provides new attack surfaces to inject code into unsuspecting victims' machines. An attacker injecting a script into a victim's computer can have devastating effects, considering the Turing-completeness of these languages.

\subsection{Suggested Countermeasures}

We have developed countermeasures based on the ideas we gained from our literature search. We specifically attempted to incorporate ML techniques into our approach. We took this step as the offered solutions will only need minor modifications to features to cover new undiscovered future attacks. This advantage of ML will make the presented techniques more adaptable. Furthermore, although signature-based malware detection is the most extended technique in commercial antivirus, they tend to fail as newer types of malware emerge \cite{santos2013opem,scott2017signature}. Artificial intelligence provides a competitive advantage over next-generation malware \cite{scott2017signature}.

Therefore, when designing our countermeasures for public registries, we incorporated ML techniques. We have not tested the solutions yet, so the feasibility of using them may be in question. Another option can be contacting the admin teams of the public registries to gain their inputs. However, we hope that this work would act as a first step to spark interest in this field and capture the attention of the admin teams of OS registries.

\subsubsection{Malicious Package Detection}

Some sources state that current tools for identifying malicious payloads are resource-demanding. However, there are lightweight tools in the literature to mitigate the risk of malware residing in the registries. These tools can be automated scanning programs to analyze the dependency tree for squatting packages \cite{vu2020towards}. The automation of reviewing published code may prove to be challenging. Nevertheless, allowing any developer to publish code into the public registry, where millions of developers have access, gives much power to any stranger.

Since the source code for every project on an OS registry is public, any user can review the code for each library. This fact is advantageous as the dependency tree and the source code of the project is visible. One antivirus designed for APIs can review packages on the registry to eliminate the time needed for the public to uncover malicious software. A member of the admin team or a volunteer can download batches of packages from the public registry to his local repository and use the antivirus to ensure the safety of each library. However, we have not found an antivirus software specifically designed to scan APIs on the internet. Antiviruses may use features that work on software for end-users. The same features may not prove efficient for libraries designed for implementing programs.

For this purpose, we will explore antivirus software that may be useful specifically for APIs. We will focus on analyzing the binary and the behavior of the library instead of its source code. We decided to cover a broader range of use cases, as we believe analyzing the source code is less challenging than an executable binary. Thus, our project can also cover library binaries for malware detection.

There has been work in the field to efficiently automate the detection of malicious code injection in the distributed artifacts of packages, and the admins may attempt to implement some of these novel tools \cite{vu2020towards}. One such tool, named \textit{Buildwatch}, analyzes the third-party dependencies by using the simple assumption that malicious packages introduce more artifacts during installation than benign libraries \cite{ohm2020towards}. This hypothesis has been formulated and tested in the \textit{Buildwatch} study \cite{ohm2020towards}. Admins can also modify \textit{Buildwatch} to detect squatting packages in the dependency tree with the techniques we will discuss in the upcoming sections.

One approach in detecting suspicious packages comes from a study that uses anomaly detection to identify suspicious software \cite{garrett2019detecting}. Their approach first extracts several features from the version when a package gets updated. It then performs k-means clustering to detect outliers for further review. The researchers kept the number of features low to ensure the clustering algorithm takes limited computation power, thus making it lightweight \cite{garrett2019detecting}. Some extracted features are the ability to send/receive HTTP requests, create/read/write to file systems, or open/listen/write to sockets \cite{garrett2019detecting}. This tool specifically uses anomaly detection, a branch of ML, to tackle the issue of detecting suspicious updates. We believe this tool is very suitable for analyzing third-party libraries.

As image classification becomes more accurate due to the development of robust classifiers such as convolutional neural networks (i.e., CNN), researchers in the field proposed visualization-based techniques to detect malicious packages. This technique would input the executable of the library to visualize its binary for processing. An advantage of binary visualization is that it does not need to disassemble the package to perform static analysis if the source code is not available. The program can directly examine the package binary.

Nataraj et al. ~\cite{nataraj2011malware} proposed a method to convert the malware binary into a gray-scale image by reading the binary as vectors of 8 bits and organizing them into a 2D array. They extracted texture features from the image representation of the malware and performed K-nearest neighbor (i.e., KNN) with Euclidean distance to classify the malware.

Ni et al.~\cite{ni2018malware} converted malware opcode sequences into gray-scale malware fingerprinting images with SimHash encoding and bilinear interpolation and used CNN to train the malware classifier. Their evaluation results revealed that their classifier outperformed support vector machine (SVM) and KNN on the features from 3-grams of the opcode, and another classifier using KNN on GIST features. The classifier reaches around 98\% accuracy and only takes 1.41s to recognize a new sample.

Besides the visualization of the binaries of libraries, which is similar to static analysis, there are other ML-based techniques. The ML-based malware detection field seems well-established as several survey papers exist, such as studies from Gandotra et al. and Ucci et al. \cite{gandotra2014malware,ucci2019survey}. They compiled various tools from the literature, and Gandotra et al. listed their limitations \cite{gandotra2014malware}.  These tools are based on static analysis, in which the code is not executed, and dynamic analysis, which focuses on the run-time behavior \cite{gandotra2014malware}. One such tool even uses data mining techniques to detect malicious executables that rely on specific features from the binary. \cite{schultz2000data}. These features are the Portable Executable, strings, and byte sequences \cite{schultz2000data}. The Naive Bayes model takes in these features and reaches an accuracy rate of 97.11\% in the study \cite{schultz2000data,gandotra2014malware}. These surveys contain several examples of malware tools that can be adapted for APIs.

In 2014, Gandotra et al. stated that many researchers lean towards dynamic analysis instead of static \cite{gandotra2014malware}. The survey gave examples of dynamic analysis techniques for malware detection \cite{gandotra2014malware}. Some examples include the work of Rieck et al. that monitors the behavior of malware on a sandbox environment \cite{gandotra2014malware,rieck2011automatic}. The observed behavior of the program is embedded into a vector space \cite{rieck2011automatic}. They use clustering to identify similar malware behaviors to classify each executable \cite{rieck2011automatic}.

To conclude the antivirus examples summary for APIs, we believe that the volunteer developers recruited via an advertisement banner on the official npmjs.com website can implement the mentioned tools and ML techniques in exchange of the trust score incentive in the following sections. Afterward, the admin team can design a protocol where a volunteer user can install batches of libraries into his local repository to allow the mentioned programs to review their safety. Developers can even automate this protocol from a web server to prevent the loss of precious human labor on repeated tasks.

If our methods are not feasible for public registries, novel tools still exist in the literature accessed from the Google Scholar platform. We could not find existing antivirus explicitly designed for libraries, but already-tested software would be a better option if admins can access it. Admins can decide to move forward with a novel tool originated from a paper, and reading academic papers can indeed be a daunting task as it is for us. However, most papers have correspondent authors that can clarify ambiguous implementation details. Some papers even have their implementations on public repositories, which will be very helpful to the team of implementers.

\subsubsection{Reasonable Constraints, Decentralization, and Trust Score}

The founding committee of an OS registry might not operate to pursue profit, and they may be short on budget to hire additional developers to implement these tools or reviewers to find malicious packages manually. However, to solve this problem, the admin teams can decentralize the manual code review process to people willing to contribute to the platform's security. Contributors can opt-in to review code and cast votes. After a new library is reviewed and voted to be published by a certain number of developers, it may be available to install on the public registry.

To encourage members of the OS registries to become reviewers, admin teams of the registries can give specific incentives for the time a reviewer invests. These perks, such as early access or discounts to products, can be supplied by companies that sponsor the npm or PyPi environment. As reviewers cast their votes to pass or reject a commit, they can earn points to unlock some advertised perks. The point system can be gamified to build public rankings and hierarchic levels. Each level would give contributors different perks, such as a free course on a partnered educational platform.

To implement the final stage of the voting-based solution, one has to take measures against the possibility of reviewers abusing the scoring system by casting votes without properly reviewing a commit. We believe there are already known solutions for this issue that does not need to be mentioned in this work. Some of these control measures can include comparing the time it takes for each reviewer to cast a vote to ensure each reviewer invests a proper amount of time. Simply observing the number of times a reviewer is an outlier based on the majority of the votes cast for a certain decision can also be observed. These solutions are merely to preserve the quality of the reviewer committees.

The scoring system can be implemented to give more privileges to users gradually besides the mentioned perks. Users can earn trust points as they actively review the contributions to projects, and users may start to publish their packages after their score passes a threshold. Thus, registries can give power to partially trusted users rather than anyone with an internet connection. We will be referencing this trust score in some of the following sections.

\subsubsection{Securing Critical Accounts}

We believe the admin teams should implement a mandatory feature in the registries. A user who maintains a popular library or a popular library that uses the user's package should automatically have multi-factor authentication (MFA) to mitigate the risk of compromised accounts. MFA should be mandatory in highly trusted accounts that pass a preset score threshold as well. Any abnormal behavior, such as login from different machines, should be recorded and processed accordingly to prevent more sophisticated attacks. This process can simply be a secret question or a one-time code.

Another possibility is integrating code authorship identification systems into OS registries, where the program would get triggered whenever a code is published from a known author. Known hackers can be profiled from their public source code to create a database of dangerous code styles that may indicate compromised accounts. This practice is a research field in itself, and it would require high investment to build such an infrastructure. However, there are already systems built to tackle this issue to an extent. One such system is demonstrated in a study that demonstrates a Deep Learning-based Code Authorship Identification System (DL-CAIS), which is language oblivious and resilient against code obfuscation \cite{abuhamad2018large}. DL-CAIS uses GitHub repositories as its dataset and reaches an accuracy of 96\% \cite{abuhamad2018large}. It first preprocesses the input code to build representation models and feeds those models into the deep learning architecture to find more distinctive features \cite{abuhamad2018large}. The architecture to be trained consists of several RNN layers and fully connected layers \cite{abuhamad2018large}. After the training, researchers use the resulting representation models to construct a random forest classifier \cite{abuhamad2018large}.

Though limiting ourselves to only known hackers may be an insufficient approach. However, npm and PyPi have the source code of each project, proving to be very advantageous to profile developers. npm or PyPi can use code authorship detection tools to profile each of its developers. Each constructed profile can be associated with a collaborator or maintainer account. If the uploaded code profile in one commit does not match the code profile of the account, the admin can place a temporary hold on the account for further verification. One may still be concerned about the privacy aspect of this approach, but the feature can be optional for non-critical accounts. An automated script can reward users with an extra trust score for opting into the program to provide incentives for this practice. However, we believe critical accounts should be required to participate, as the cost of an account compromise would be significantly higher in their case.

\subsubsection{A Proposed Solution for Technical Lag}

One feature in the npm environment we would like to see removed is the ability to constrain the specific version of a dependency by default in the package.json file \cite{zimmermann2019small}. We believe that there should be a special keyword in package.json, such as \textit{xxx}, for the npm to check the most updated version in its registry and install it automatically to mitigate the issue of technical lag. The keyword \textit{npm outdated} may be unknown to some developers, or the additional workload it would add can be a deterrent factor. However, the keyword that indicates the most recent version should be a default or auto-filled by the package manager to avoid the user interfering with versions. However, this also presents the danger of an update breaking existing systems. The user should always have the option to fix the dependency to a specific version as some releases will provide long-term support or better stability. Thus, the user can have the freedom to decide if the security or functionality of the project is a priority.

Frameworks have also been developed to measure how outdated a system is, balancing security and functionality \cite{gonzalez2017technical,zerouali2019formal}. Calculating a project's recentness score may prove difficult, as each project will have its priorities, such as performance or stability \cite{gonzalez2017technical}. Gonzalez et al. name this priority as "gold standard" and defines the gold standard to build a lag function that can output the recentness score \cite{gonzalez2017technical}. For instance, if the user chooses his gold standard as security, the lag function can focus on the number of new updates related to security \cite{gonzalez2017technical}. If the gold standard is functionality, the lag function can take the number of new features into account \cite{gonzalez2017technical}. Gonzales et al. even propose other possible lag functions, such as one that simply measures the differences in lines of source code between the most recent and currently deployed dependency or the number of commits of difference between them \cite{gonzalez2017technical}.

To partially implement the framework in npm or PyPi registries, they can mandate reputable libraries to list and classify each update done with the commit. Users can specify their "gold standard" with a specific command after the creation of their projects. npm can use this gold standard to compare the score of the current dependencies with their most recent versions. Now, the user will know his dependencies' recentness in terms of his priorities. Thus, the user can make more informed decisions on whether he should update.

Registries do not have to undergo significant changes to calculate the current projects' scores, as npm can simply take their score as 0. If all future versions require the contributor to classify new features or bug fixes manually, we believe it will not be challenging to implement the new system. Currently, we do not expect to calculate the significance of each particular update, but the user can be asked to assign a score of significance to each bug fix or new feature. We expect several users to avoid spending time with the classification of new features; however, npm can provide incentives to encourage users to participate in the program, such as with extra perks or trust scores.

\subsubsection{Automatic Eviction of Squatters}

The brute force solution of this problem can be a function that compares the name similarity of a newly published package to an already existing library to determine suspicious packages. Any new package upload can trigger the npm registry to invoke a script that compares the uploaded library name to every other package name in the registry. Suppose the similarity result passes a certain threshold. In that case, the registry can automatically reject the uploaded package, informing the publisher that the package name is too similar to an existing one, and he should choose a new name. However, this approach may prove to be insufficient as the script may not be able to capture every possible scenario.

A simple countermeasure in the literature is the tool TypoGard. It implements a novel detection technique, which uses both the lexical similarity of the package names and the package popularity \cite{taylor2020defending}. It flags certain cases where a user would download an unknown package with a similar name to a popular one before the library can be installed \cite{taylor2020defending}. The tool even caught previously unknown attack attempts, including a package named \textit{loadsh} that imitates the popular npm package \textit{lodash} \cite{taylor2020spellbound}. An advantage of TypoGard is that it can simply run on the client-side and requires no cooperation from repositories \cite{taylor2020defending}. Researchers evaluated TypoGard on npm, PyPi, and RubyGems, and it has achieved an accuracy of 99.4\% with flagging cases \cite{taylor2020defending}. The researchers also measured the overhead of TypoGard and determined it is only 2.5\% of the install time \cite{taylor2020defending}. We found that TypoGard is also known as SpellBound in the literature \cite{taylor2020spellbound}.

Squatting also exists in DNS servers, and researchers proposed ML-based solutions to identify suspected squatters in the past \cite{moubayed2018dns}. One study proposes approaches based on supervised learning. It specifically uses an ensemble learning classifier that uses various algorithms, such as SVM, that reach an accuracy rate of 88.4\% \cite{moubayed2018dns}. The study also uses unsupervised learning to identify suspicious domain names by implementing K-means clustering based on specific futures extracted from domain names \cite{moubayed2018dns}. Here, the key takeaway seems to be the features chosen to reach this accuracy, such as the number of unique letters or unique numbers in a domain name \cite{moubayed2018dns}. For the OS registries case, developers tasked with implementing countermeasures can examine past squatting attacks to create potential features to identify squatters. The features are mostly derived initially by making assumptions of what commonalities of past squatter packages have. These features can even be created by guessing, then feeding them to the ML algorithm to observe which produces the highest accuracy rates.

\subsection{Future Direction}

First and foremost, all of our suggested countermeasures are theoretical as none of them has been tested in a real-world scenario. We can do additional work by reaching out to the OS registries' admin teams to conduct interviews on the feasibility of our solutions. The admin teams can also have the chance to voice their opinions and common issues they encounter. Based on the issues OS registries face, we may modify some of our solutions or search for additional tools in the literature to meet the admin team's requirements.

To apply ML in the real world for malicious package detection, we need to ensure that the ML model is robust enough against adversarial examples. Adversarial examples are carefully crafted samples to fool the ML model. Previous work has already illustrated how a clever attacker can augment the correctly classified malware with malicious components to cause the ML model to misclassify it~\cite{khormali2019copycat,kolosnjaji2018adversarial,demetrio2020adversarial,sharif2019optimization}. These attacks mostly inject malicious components to the non-reachable parts of the malware, such as padding bytes to the end of the malware or injecting malicious payload to the malware's DOS header. In this way, they can ensure that the original malware purpose is still maintained. However, these attacks can be filtered easily by embedding a code cleaning process into the malicious package detector to filter out non-reachable codes. A more powerful attack can also inject malicious components into the code section~\cite{sharif2019optimization}. These attacks are more difficult to detect, and further study is required to develop defenses against them.

A useful approach to ease the burden of manual code reviewing for uploaded packages is to measure their similarity to the previously reviewed packages. Suppose the uploaded package is similar to a known malicious package. In that case, it might raise a warning immediately, which can help the reviewers decide whether to reject it into the registry. ML approaches are well suited for detecting code similarity. Previous work provides several ML approaches to detect code similarity in binary-level~\cite{shalev2018binary,wang2017memory,marastoni2018deep} or decompiled code level~\cite{ullah2021software}. Existing use cases of the proposed methods focus more on detecting software plagiarism and IP theft. Other use cases such as detecting malicious packages are still worth exploring.

Another possible future direction is a project focused on the cost-benefit analysis of using OS package registries. Different organizations with various sizes, fields, or interests may have outweighing benefits or costs using the OS ecosystem, and it is worthwhile to examine the analysis. The aspects of OS security do not seem to be either white or black, and sometimes the risks may justify the benefits for a particular use case.

Future work can also extend the survey to other OS tools aside from public registries. Several companies create internal versions of OS projects to avoid potential hazards. However, these internal versions are closed source, and the OS community cannot benefit from additional features implemented within the firm. Informing the academic society about the security hazards of other OS tools and providing risk mitigation strategies may attract businesses to adopt and actively maintain these projects, thus benefiting the OS community.

\section{Conclusion}

It seems that research cannot completely remove the risks of npm and PyPi as OS projects mainly rely on volunteer humans and public access. It would be justifiable to assume that these factors constantly create new attack surfaces. The OS registries are open to the public and maintained by humans; however, risk mitigation strategies can be implemented, such as requiring the contributors to use MFA or implementing a trust-score system. It is essentially a trade-off between convenience and security. Nevertheless, the possible opportunity cost of the lack of security must be deliberated carefully before reaching a decision.

One must consider the needs of every individual and establishment when developing software. Certain companies cannot risk a possibility of a data breach as their reputation loss in monetary terms would be much larger than maintaining an army of software developers to convert OS tools to closed source. The lack of trust in the registries would deprive the OS community of the potential knowledge the employees of these firms can bring into the field. A concrete example of this issue is that the Department of Defense is concerned about certain dependencies of their projects being out of their control. This concern would justifiably cause them to refrain from using OS platforms \cite{ellison2010evaluating}. With countermeasures born from OS security research, admin teams can minimize the risk. The risk can be minimal to the point where some high-security clearance companies may use and even contribute to certain OS packages. Thus, they will strengthen the OS society even further and make software accessible to anyone.

\bibliographystyle{splncs04}

redpajama_set_name: RedPajamaArXiv


Korea Otsuka Pharmaceutical Co., Ltd.
SANS(Scale for the Assessment of Negative Symptoms), NIDSS(Neuroleptic induced Deficit Syndrome Scale) In NIDSS, the average of number 1 to 5 is blunted affect, the average of number 16 to 20 is avolition, the average of number 6 to 15 is cognition, the average of all score is total.
Minimum of NIDSS(avolition, blunted affect, cognition, total) is -3, maximum is +3.(subscale score and total) '+' is better outcome, '-' is worse outcome. Minimum of SANS-Global score for alogia and blunted affect is 0, Maximum of SANS-Global score for alogia and blunted affect is 5 The higher number is worse outcome. The zeros are measured and Calcuated value This outcome measure is reporting a change between baseline and 2hr after third medication.
DIEPSS(Drug-Induced Extrapyramidal Symptoms Scale), VAS(Visual analog scale);mental sedation (alert–drowsy, muzzy–clear headed, mentally slow–quick witted, attentive–dreamy), physical sedation (strong–feeble, well coordinated–clumsy, lethargic–energetic, incompetent–proficient), tranquilization (calm–excited, contented–discontented, troubled–tranquil, tense–relaxed), and other types of feelings (happy–sad, antagonistic–amicable, interested–bored, withdrawn–gregarious) Minimum of VAS(Mental sedation score,Physical sedation score,Total score) is 0, Maximum is 10.
VAS-total score is average of all subscale scores. Minimum of DIEPSS is 0, Maximum is 4. The higher number is worse outcome. The score ranges are for subscale score. This outcome measure is reporting a change between baseline and 2hr after third medication.
DIEPSS(Drug-Induced Extrapyramidal Symptoms Scale), VAS(Visual analog scale);mental sedation (alert-drowsy, muzzy-clear headed, mentally slow-quick witted, attentive-dreamy), physical sedation (strong-feeble, well coordinated-clumsy, lethargic-energetic, incompetent-proficient), tranquilization (calm-excited, contented-discontented, troubled-tranquil, tense-relaxed), and other types of feelings (happy-sad, antagonistic-amicable, interested-bored, withdrawn-gregarious) Minimum of VAS is 0, Maximum is 10 Minimum of DIEPSS is 0, Maximum is 4 The higher number is worse outcome. The score ranges are for subscale score. This outcome measure is reporting a change between baseline and 50hr after third medication.
CNT(Computerized Neuro-Cognitive Function Test System); The tests included a word fluency test. All of the assessments except the CNT were conducted immediately prior to administration of the medication and at 2 (for risperidone and placebo) or 24 h (for paliperidone ER) after the first and third administrations of the study medications.
Minimum of Wisconsin card sorting test-Category completed is 0, Maximum is 6, the lower number is worse outcome.
Minimum of Wisconsin card sorting test-Perseverative response and Trials to complete is 0, Maximum is 128, the lower number is worse outcome.
Minimum of Wisconsin card sorting test-Perseverative error is 0, Maximum is 128, the higher number is worse outcome.
Minimum of Word-fluency test is 0 and no maximum value, the higher number is better outcome.
The score ranges are for subscale score. This outcome measure is reporting a change between baseline and 50hr after third medication.
SANS(Scale for the Assessment of Negative Symptoms), NIDSS(Neuroleptic induced Deficit Syndrome Scale) Minimum of NIDSS is -3, maximum of NIDSS is +3. '+' is better outcome, '-' is worse outcome. Minimum of SNAS-Global score is 0, Maximum of SNAS-Global score is 5 The higher number is worse outcome. The zeros are measured and Calcuated value. The score ranges are for subscale score. This outcome measure is reporting a change between baseline and 50hr after third medication.
CNT(Computerized Neuro-Cognitive Function Test System); The tests included the Stroop test, Trail-Making Test B (TMT B). All of the assessments except the CNT were conducted immediately prior to administration of the medication and at 2 (for risperidone and placebo) or 24 h (for paliperidone ER) after the first and third administrations of the study medications Minimum of Stroop test is 0, no maximum limit, the higher number is worse outcome.
Minimum of Trail making test B is 0 and no maximum limit, the higher number is worse outcome.
CNT(Computerized Neuro-Cognitive Function Test System); The tests included Wisconsin Card-Sorting Test (WCST). All of the assessments except the CNT were conducted immediately prior to administration of the medication and at 2 (for risperidone and placebo) or 24 h (for paliperidone ER) after the first and third administrations of the study medications.
Minimum of Wisconsin card sorting test-Trials to complete first category trials is 0, Maximum is 128 and minimum of Wisconsin card sorting test-Perseverative error is 0, Maximum is 128, the higher number is worse outcome.


Tickle My Tastebuds Tuesday #214 is LIVE featuring More Fall Foods!
Happy October! Holy moly this year has flown by. Next thing you know, it will be New Years… OK, lets not hurry the year along. I'm glad you're back and can't wait to see what you link up today.
I thought I would do one more group of fall features before moving on to our first holiday of the season; Halloween. So please…. please link up all your Halloween deliciousness from cute cupcakes to spooky cookies. Or a main dish to please the ghosts and goblins in your family. Or just something orange. I really want to see your Halloween dishes!
Here are your fantastic fall features!


text:
package org.robolectric.res;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.InputStream;

public class RawResourceLoader {

    private ResourceIndex resourceIndex;
    private File resourceDir;

    public RawResourceLoader(ResourceIndex resourceIndex, File resourceDir) {
        this.resourceIndex = resourceIndex;
        this.resourceDir = resourceDir;
    }

    public InputStream getValue(int resourceId) {
        String resourceFileName = resourceIndex.getResName(resourceId).name;
        File rawResourceDir = new File(resourceDir, "raw");

        File[] files = rawResourceDir.listFiles();
        if (files != null) {
            for (File file : files) {
                String name = file.getName();
                int dotIndex = name.indexOf(".");
                String fileBaseName = dotIndex >= 0 ? name.substring(0, dotIndex) : name;
                if (fileBaseName.equals(resourceFileName)) {
                    try {
                        return new FileInputStream(file);
                    } catch (FileNotFoundException e) {
                        throw new RuntimeException(e);
                    }
                }
            }
        }
        return null;
    }

}


Find here best of green color walls. Some times ago, we have collected portrait to add more bright vision, we think that the above mentioned are amazing portrait. Hopefully useful. Desert bougies can provide great color your garden, Side wall mostly stems some leaves into hedges reduce new bract formation thus lose color one variety called purple queen produces more bright green lush bracts hold long have.
If you like these picture, you must click the picture to see the large or full size picture. If you think this collection is useful to you, or maybe your friends please click like/share button, maybe you can help other people can get these collection too. Here there are, you can see one of our green color walls collection, there are many picture that you can found, don't forget to see them too.
Once completed, you possibly can truly take a digital tour of your new kitchen and really see how the space will really feel. When making your decision, candy blood red paint keep in mind how the material will be used and also the drape of the material. The main focus must be to improvise on the performance whereas retaining the aesthetic half in thoughts. It does away with the storage woes completely and the most important half is that it still uses the classic kitchen triangle. It brings in more storage space into the kitchen. You can move furnishings and appliances round to offer you an concept of the best way to get probably the most out of the area. It's useful to have this visual support and it will assist companies get a greater idea of the type of kitchen you're after. Even if you are planning at hand the job over to skilled kitchen designers at the first alternative, it's value enjoying around with a free version of the software to get an thought of what you need.
For example, a less complicated version will simply ask you to enter just a few details and will then render you a simple drawing that you could then take to indicate kitchen designers. Go a step further and order a small quantity of fabric, as an example, ¼ yard and pin together a miniature window remedy that you just place round your window. Texture is an effective method to deliver curiosity to your window therapies if having pattern at the window shouldn't be your style. Do you want free-standing furniture or are built-in furnishings more your fashion? It also provides you the possibility to experiment with totally different color schemes and furnishings layouts to see what works and what would not. If you're beginning a kitchen design you may want to give yourself every chance of getting issues measured out proper first time, which is the place a kitchen planner can are available in helpful. A kitchen planner is laptop software program that lets you draft out precisely the way you want your new kitchen to look.
If you have a long and slim kitchen then you definately may need to go for the one wall kitchen design. But if you want to maximise the storage space, then this is not the perfect design. If you're focused on exploring the possibilities of what you are able to do together with your kitchen, then there are superb 3D kitchen planners you may get your arms on. They take somewhat more effort and time, but the outcomes you'll be able to obtain are outstanding. Consider the size of the sample so it would not overwhelm the window or be so refined it could actually hardly be seen from a distance. In case you are in doubt of the shade for your window therapies, choose curtain fabrics which might be a bit lighter than the colour of your partitions.
There are lots of these available online. If you have any concerns with regards to exactly where along with the best way to employ jordans, it is possible to call us from our web site. Next, ethan allen floral sofa spend loads of time deciding on a fabric. Take dwelling a couple of swatches of fabric to see how the colors and patterns mix in your room. Several designs just like the corridor design use the basic kitchen triangle to maximise its effectiveness. You may need to make use of the L formed design plans along with this one. The classic triangle is undoubtedly probably the most famous kitchen designs to have been ever invented. Unlike the kitchen triangle, which is a highly regarded design this one has a linear design. The entire movement of the kitchen ought to change while you remodel it. It paves method for easy functioning and flow of labor within the kitchen. There are some actually outdated tried and tested kitchen design plans that work.
If you're not significantly pc savvy fear not, there are kitchen planners to swimsuit everyone. More and more of us are taking an lively interest in our kitchen design and as such, a kitchen planner is an effective way to do that. For most individuals, kitchen design is all about updating the appliances and cabinetry in the kitchen. You must choose one from amongst these based on the scale and shape of your kitchen. That is one in all the best and inexpensive designs. A triangle is formed with the sink, the oven/stove and the refrigerator at every ends. The L shaped design is ideal for large kitchens that all the time seem crowded. Needless to say this is extremely helpful and the neatest thing about it is that it's totally easy.
Below are 10 top images from 15 best pictures collection of green color walls photo in high resolution. Click the image for larger image size and more details.


CAFE SIK opened in September 2015, right in the heart of Osaka City, next to Utsubo Park.
Our main concept is based on 'a select shop where our customers experience new kinds of unique food and flavours'.
a wine bar and a beautiful garden terrace with the view of Utsubo Park and its famous rose garden.
This atmosphere will allow you to enjoy a wonderful time with great friends, family and coworkers.
CAFE SIK is located right next to the stunning Utsubo Park and has a floor space of 231.4 square metres.
It is located in the Nishi-ku area of Osaka city.
and a path with Japanese zelkova trees that provide a lovely shade for a nice and relaxing walk.
aleternoon tea parties and other events are held.
Copyright 2019 CAFE SIK All Rights Reserved.


text:
Lillian Adams (ur. 13 maja 1922 w Nowym Jorku, zm. 25 maja 2011 w  Los Angeles) – amerykańska aktorka.

Filmografia
 Suite Life: Nie ma to jak statek (2008) jako Pani Piperman
 Brzydula Betty (2006) jako Esther
 Bruce Wszechmogący (2003) jako Mama Kowolski
 Dwóch i pół (2003) jako Pani Freemantle
 Zwariowany świat Malcolma (2000) jako Mona 6
 Becker (1998) jako Pani Rowick
 Dharma i Greg (1997) jako Pani Spinoza
 Wings (1990) jako starsza pani
 Murphy Brown (1988) jako Estelle
 Out of This World (1987) jako Evie
 Archie Bunker's Place (1979) jako Pani Plotkin
 The Jerk (1979) jako Tillie
 Ironside (1967) jako Pani Farber
 Family Affair (1966) jako Pani Mariani
 Po tamtej stronie (1963) jako Mama Dixa
 Millennium (1959) jako Kiri Hawks
 Whirlybirds (1958) jako Drugstore Clerk

Bibliografia

Amerykańskie aktorki filmowe
Urodzeni w 1922
Zmarli w 2011
Ludzie urodzeni w Nowym Jorku

redpajama_set_name: RedPajamaWikipedia