WO2022038407A1

WO2022038407A1 - Remote compiling and signing kernel modules

Info

Publication number: WO2022038407A1
Application number: PCT/IB2020/060829
Authority: WO
Inventors: Lior SHARON; Michael Gorelik; Mordechai GURI; Nathaniel TSECHANSKI
Original assignee: Morphisec Information Security 2014 Ltd.
Priority date: 2020-08-17
Filing date: 2020-11-17
Publication date: 2022-02-24

Abstract

Methods, systems and computer program products are described that implement a binary provider system. In one aspect, the system is configured to receive a request for a compiled binary from an endpoint, the request including endpoint configuration information. In response to receiving the request, a determination is made as to whether the requested binary is maintained by the system. Where the binary is maintained by the system, a copy of the binary is provided to the endpoint. Where the binary is not maintained by the system, the binary is generated based in part on the endpoint configuration information, and subsequently provided to the endpoint. The system may determine whether the binary is signed, and whether the binary is to be signed. Where the binary is not signed and is to be signed, the binary is signed, and the signed binary is subsequently provided to the endpoint.

Description

REMOTE COMPILING AND SIGNING KERNEL MODULES

BACKGROUND

[0001] Numerous modem operating systems comprise free and open-source software (“OSS”). Organizations both public and private, whether engaged in commerce, research, education or other endeavors, often choose to use such free operating systems because it makes financial sense for them to do so. In the context of academic research, for example, research grants are often scarce, and opting to use free and open-source operating systems for research computers saves money that would otherwise be required to purchase a license for a commercial, closed-source operating system.

[0002] Moreover, OSS operating systems such as, for example, Linux typically have more modest resource requirements both in terms of storage and/or system memory, and may be better suited for use in certain types of devices with embedded computer systems (e.g., a touch-screen kiosk).

[0003] Using OSS operating systems is not, however, without its downsides. The Linux operating system, for example, is available in many different distributions. A Linux distribution is an operating system made from a software collection that is based upon the Linux kernel and usually a package management system. Linux users may obtain their operating system by downloading one of these distributions. A typical Linux distribution includes the Linux kernel, tools, libraries and other software, documentation, a window system such as the X Window System, a window manager, and a desktop environment.

[0004] As mentioned above, each distribution is based on a common kernel. Whenever there is a change to the underlying kernel, such changes must be propagated to end user installations, and the requirements for doing so vary from distribution to distribution. In some instances, a binary patch may be applied and in other situations the kernel must be re-built from scratch particularly where the end user has created custom kernel extensions. Furthermore, software developers may wish to distribute software to end users without disclosing its underlying source code. In such instances, it is not possible for an end user to build or re-build such software when its operation is impacted by a change to the kernel. Accordingly, organizations that manage a large number of workstations and/or servers may find it difficult to keep such machines up-to-date and functioning particularly where end-users have customized the operating systems of such machines.

SUMMARY

[0005] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0006] Methods and systems are described herein that implement a binary provider system. In one aspect, the binary provider system is configured to receive a request for a compiled binary from an endpoint, the request including endpoint configuration information. In response to receiving the request, a determination is made as to whether the compiled binary requested by the endpoint is maintained by the binary provider system. In the event that the compiled binary is maintained by the binary provider system, a copy of the compiled binary is provided to the endpoint. In the event the compiled binary is not maintained by the binary provider system, the compiled binary is generated based in part on the endpoint configuration information, and subsequently provided to the endpoint.

[0007] In a further aspect, the binary provider system may determine whether the copy of the compiled binary is signed, and whether the copy of the compiled binary is to be signed. Where the copy of the compiled binary is not signed and is to be signed, the copy of the compiled binary is signed, and the signed, compiled binary is subsequently provided to the endpoint.

[0008] Further features and advantages, as well as the structure and operation of various examples, are described in detail below with reference to the accompanying drawings. It is noted that the ideas and techniques are not limited to the specific examples described herein. Such examples are presented herein for illustrative purposes only. Additional examples will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

[0009] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present application and, together with the description, further serve to explain the principles of the embodiments and to enable a person skilled in the pertinent art to make and use the embodiments.

[0010] FIG. 1 depicts an example remote compilation system, according to an embodiment.

[0011] FIG. 2 depicts a table of example mappings between binaries and configuration information, according to an example embodiment.

[0012] FIG. 3 depicts a flowchart of a method of providing a compiled binary from a remote compilation system, according to an example embodiment.

[0013] FIG. 4 depicts a flowchart of a method for providing a signed, compiled binary from a remote compilation system, according to an example embodiment.

[0014] FIG. 5 is a block diagram of an example computer system in which embodiments may be implemented.

[0015] The features and advantages of embodiments will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

DETAILED DESCRIPTION

I. Introduction

[0016] The present specification and accompanying drawings disclose one or more embodiments that incorporate the features of the present invention. The scope of the present invention is not limited to the disclosed embodiments. The disclosed embodiments merely exemplify the present invention, and modified versions of the disclosed embodiments are also encompassed by the present invention. Embodiments of the present invention are defined by the claims appended hereto. [0017] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0018] In the discussion, unless otherwise stated, adjectives such as “substantially” and “about” modifying a condition or relationship characteristic of a feature or features of an embodiment of the disclosure, are understood to mean that the condition or characteristic is defined to within tolerances that are acceptable for operation of the embodiment for an application for which it is intended.

[0019] Numerous exemplary embodiments are described as follows. It is noted that any section/subsection headings provided herein are not intended to be limiting. Embodiments are described throughout this document, and any type of embodiment may be included under any section/subsection. Furthermore, embodiments disclosed in any section/subsection may be combined with any other embodiments described in the same section/subsection and/or a different section/subsection in any manner.

II. Example Embodiments

[0020] Embodiments disclosed herein provide a remote, cloud-based build system that serves as a centralized source for updated or customized kernel modules or other binaries, including binaries built from proprietary source code. Such embodiments reflect an improvement in the technical field of computers and the functioning of a computer, by enabling the centralized management of custom binary builds of operating system kernels and other applications. Such centralized management improves the functioning not only of endpoint computers, but also of an entire information technology (“IT”) infrastructure inasmuch the redundancies inherent in numerous endpoints each building their own binaries is eliminated. Furthermore, the centralized build system improves security of endpoint computers and the IT infrastructure by propagating needed binary updates to endpoint computers where such updates include necessary security updates, and by providing a centralized means of applying digital signatures to such binaries. Furthermore, another advantage of distributing binaries is that any underlying source code used to generate such binaries remains private/secure. A remote, cloud-based build system may be implemented in various ways. For example, FIG. 1 depicts an example remote compilation system 100, according to an embodiment.

[0021] As shown in FIG. 1, remote compilation system 100 includes an endpoint 102, a cloud-based binary provider 104, and a developer endpoint 106. Endpoint 102 includes a custom package manager 108. Cloud-based binary provider 104 includes a metadata obtainer 110, a compilation subsystem 112, a binary provider 116 and a data store 118. Compilation subsystem 112 includes compilation units 120-1 through 120-n, and a signing unit 114. Cloud-based binary provider 104 is communicatively coupled to developer endpoint 106 and endpoint 102 via one or more networks, such as, but not limited to, local area networks (LANs), wide area networks (WANs), the Internet, etc., and may include one or more of wired and/or wireless portions. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding remote compilation system 100 as depicted in FIG. 1.

[0022] Endpoint 102 is a client computing device that is running an operating system such as, for example, a distribution of the Linux operating system. It should be understood, however, that the Linux operating system and Linux distributions as discussed herein, and other operating systems/distributions may be employed in embodiments. For example, embodiments may employ various flavors of the Berkeley Software Distribution (“BSD”) such as FreeBSD, OpenBSD and the like. Likewise, various Unix or Unix-like operating systems such as OS X, Solaris, Xenix and the like, may also employed, in embodiments. Endpoint 102 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a laptop computer, a notebook computer, a tablet computer, a netbook, etc.), a wearable computing device (e.g., a head-mounted device including smart glasses such as Google® Glass™, etc.), or a stationary computing device such as a desktop computer or PC (personal computer).

[0023] In embodiments, custom package manager 108 is a software component executing on endpoint 102 that manages the installation of custom operating system components, including kernel space modules/drivers, and updates thereto. Custom package manager 108 may be a user space application comprising one or more utilities running as a service or daemon. Alternatively, custom package manager 108 may run as part of a customized kernel.

[0024] Custom package manager 108 is configured to determine and gather endpoint information (or metadata) 140 that corresponds to aspects of the operating system and/or applications installed on endpoint 102. For instance, custom package manager 108 may determine endpoint information corresponding to the kernel of the operating system installed on endpoint 108. Such endpoint information may include, but is not limited to, the following types of information that correspond to the operating system that is installed on endpoint 102: kernel headers (e.g., Linux headers), a kernel version number (e.g., vermagic number or other identifier) of the kernel, an identifier and/or version number of the operating system distribution (e.g., Debian, openSUSE, Fedora, FreeBSD, and the like), an identifier of one or more applications installed on endpoint 102 and/or the identity and version of a compiler version utilized to compile the operating system distribution or kernel and/or application(s) installed on endpoint 102.

[0025] Custom package manager 108 may also be configured to gather endpoint information 140 corresponding to aspects of the computer hardware that comprises endpoint 102. For example, endpoint information 140 may further comprise the computing architecture (e.g., x86, x86_x64, ARM or ARM64) of endpoint 102, the hardware configuration of endpoint 102 including, for example, the number and/or type of processors and/or type thereof, an amount of memory and/or type thereof, a number and/or type of input/output (I/O) devices installed thereon, and the like utilized by endpoint 102,

[0026] Custom package manager 108 may determine endpoint information 140 in various ways in one or more embodiments. For example, custom package manager 108 may determine endpoint information 140 (or portions thereof) by querying the default package manager that corresponds to the operating system distribution installed on endpoint 102. For example, the default package manager on most Ubuntu distributions is Advanced Packaging Tool more familiarly known as ‘apt’ (which is also the name of the shell command for invoking various package management functions). In embodiments, a package manager front-end such as, for example, aptitude may be used. Aptitude is a front-end to the default apt package manager on Debian based systems such as, for example, Ubuntu. In other embodiments, other default package managers may be employed depending on the specific build target, such as, zypper on the openSUSE distribution, or pkg on FreeBSD. It should be understood, however, such default package managers described above are merely exemplary, and embodiments may employ any package manager for determining endpoint information 140 or portions thereof. For example, the default package manager may be used to obtain the kernel headers (shown as kernel headers 130) by downloading the headers from one or more repositories 122 associated with the operating system distribution (and version thereof) installed on endpoint 102. Alternatively, custom package manager 108 may be used to obtain kernel headers by downloading them from one or more repositories, or by obtaining them from an existing custom or private repository (e.g., where the underlying OS is itself comprises a custom build).

[0027] Custom package manager 108 may also query the operating system executing thereon to determine additional endpoint information 140. For example, in certain embodiments, custom package manager 108 may be able to determine a kernel build version, operating system identifier, computing architecture, etc. It is noted that some or all of this information may also be obtained via the kernel headers. In some instances, custom package manager 108 may determine compiler versions of the systems and/or applications installed on endpoint 102 by executing an operating system shell command or other tool (e.g., dpkg, rpm, yum, apt, etc). Embodiments may likewise scan the system to determine what tools are available for use prior to executing such commands. Other commands may be performed for obtaining endpoint information 140 such as the Linux version, or as known in the art (e.g., dmesg I grep “Linux version”). One should appreciate, however, that such example commands are merely exemplary and embodiments are not so limited.

[0028] The above described ways of determining endpoint information 140 are, however, merely examples. That is, although numerous automated or semi -automated may be employed in various embodiments for determining endpoint information 140, such information may be manually provided either in whole or in part by an end user. In one embodiment, for example, an end user may be presented with a wizard user interface that queries the end user for different types of endpoint information 140. In an alternative embodiment, an end user may create and/or modify a build configuration file that includes endpoint information 140.

[0029] In embodiments, custom package manager 108 is configured to provide endpoint information 140 to cloud-based binary provider 104 as depicted in FIG. 1. Cloud-based binary provider 104 may comprise one or more computing devices (e.g., nodes or servers) implemented in a cloud-based computing platform. As described above, cloud-based binary provider 104 includes metadata obtainer 110. In an embodiment, metadata obtainer 110 is configured to accept endpoint information 140 from custom package manager 108, and thereafter store endpoint information 140 in data store 118.

[0030] Data store 118 is likewise configured to store source code and/or binaries for various application(s), operating system(s) and/or distribution(s) and kemel(s) thereof. For example, data store 118 of cloud-based binary provider 104 may accept and store developer provided source code or binary 125 from developer endpoint 106. Although cloud-based binary provider 104 is depicted in FIG. 1 as being coupled to only a single developer endpoint 106 (i.e., developer endpoint 106), it should be understood that source code and/or binaries for the application(s), operating system(s) and/or distribution(s) and kemel(s) may be provided by any number of developer endpoints 106. It is also noted that while cloud-based binary provider 104 is shown as being coupled only a single endpoint (i.e., endpoint 102), it should be understood that cloud-based binary provider 104 may be coupled to any number of endpoints. Moreover, although data store 118 of cloud-based binary provider 104 is depicted in FIG. 1 as a single data store, embodiments may employ multiple data stores. For example, embodiments may employ one or more data stores dedicated to storing different types of information. That is, data store 118 may comprise multiple database servers dedicated to storing each of endpoint information 140, source code, binaries, and the like. Moreover, multiple redundant copies of data store 118 may exist, in embodiments, for availability/reliability purposes.

[0031] Developer endpoint 106 represents one or more computing device(s) utilized by developers to develop and/or provide operating system kernels, applications or module (e.g., driver) source code 124. Such source code 124 may be proprietary source code, although the embodiments described herein are not so limited. It should be understood, however, that developer endpoint 106 may provide not only software source code, but may also provide software code that, although not human readable, may nevertheless be used in whole or in part to generate a binary (e.g., binary 126) for endpoint 102 (as described in further detail below). For example, source code 124 maintained by developer endpoint 106 may be compiled to one or more binaries (e.g., binary 126). Thus, in embodiments, developer endpoint 106 may subsume some or all of the functionality of compilation subsystem 112, particularly where an end user/developer/organization corresponding to developer endpoint 106 wishes to impose strict confidentiality limits on source code 124. In an embodiment, cloud-based binary provider 104 may expose API (not shown in FIG. 1) to one or more of developer endpoint 106 to enable such endpoints to function as in the manner of compilation subsystem 112 while keeping source code 124 held private. As such, cloud-based binary provider 104 may be construed as a publicprivate hybrid cloud-based binary provider inasmuch as the portions of the platform dedicated to obtaining endpoint information 140, storage of endpoint information 140, source code or binaries at data store 118, or provision of binaries by binary provider 116 is may be homed in a public cloud, and compilation subsystem 112 may be maintained in a private cloud at one or more developer endpoints 106. Naturally, such a public-private hybrid may employ a divided or distributed data store 118 as described above.

[0032] Source code 124 may comprise, for example, object code, symbolic assembly code, byte code and/or pre-compiled binary code. Any number of developer endpoints 106 may be communicatively coupled to cloud-based binary provider 104, each of which may be associated with a different developer and/or publisher. Accordingly, data store 118 may store source code for operating system(s) application(s), module(s), etc. associated with any number of developer(s) and/or publisher(s). As will be described below, data store 118 may also store binaries (i.e., source code that has been compiled into binaries). The binaries stored by data store 118 may include binaries (e.g., binary 126) provided by developer endpoint 106 or, as will be described below, binaries generated by compilation subsystem 112.

[0033] As described above, changes to the operating system kernel that occur due to, e.g., an operating system update performed on endpoint 102 may necessitate updates to any and all custom components installed on endpoint 102. In such instances, custom package manager 108 may detect that the kernel has changed and in response thereto, provide a request to cloud-based binary provider 104 to provide replacement binaries for any custom kernel modules or other applications that would or have been rendered useless by the operating system update. Alternatively, an end user of endpoint 102 may manually invoke such a request before or after an operating system update to endpoint 102.

[0034] The request generated by custom package manager 108 and transmitted to cloudbased binary provider 104 may specify the modules (e.g., kernel modules, drivers, etc.) that are to be updated. The request may further include endpoint information 140 as determined by custom package manager 108, and as described above. Alternatively, custom package manager 108 may periodically query cloud-based binary provider 104 to determine if any updated modules are available.

[0035] In an embodiment, a request including endpoint information 140 may be received by metadata obtainer 110 of cloud-based binary provider 104. In other embodiments, however, the request may be received by one or more other components (not shown in FIG. 1) configured to parse and act upon the request, and likewise forward endpoint information 140 to metadata obtainer 110 for further action as described herein below.

[0036] Responsive to receiving the request, one or more components of cloud-based binary provider 104 may determine which, if any, re-compiled binary modules need to be provided to endpoint 102. For example, metadata obtainer 110 may be configured to determine, based in whole or in part on endpoint information 140 what re-compiled modules should be provided to endpoint 102. Alternatively, the request may also expressly identify a binary module being requested by endpoint 102.

[0037] In an embodiment, metadata obtainer 110 may thereafter query data store 118 to determine if the requested or required binary compiled in accordance with the endpoint information 140 (e.g., against the kernel build version) is maintained therein and if so, may direct binary provider 116 to provide a copy of the stored binary to the custom package manager 108 executing on endpoint 102. In an embodiment, each binary maintained in data store 118 is associated with respective configuration information. Metadata obtainer 110 may determine if the requested or required binary is maintained by cloud-based binary provider 104 (e.g., is stored in data store 118 of cloud-based binary provider 104) by comparing endpoint configuration information included in endpoint information 140 to the configuration information corresponding to each binary maintained by cloud-based binary provider 104, and selecting a suitable match. [0038] Embodiments may track mappings between endpoint configuration information and available binaries in various ways. For example, FIG. 2 depicts a table 200 of example mappings between binaries and configuration information, according to an example embodiment. In an embodiment, table 200 may be maintained by cloud-based binary provider 104 to compare against endpoint information 140. However, embodiments are not strictly limited to such a configuration. Table 200 of FIG. 2 includes binary identifiers 202 and configuration information 204. Configuration information 204 of table 200 may include various types of configuration information including, OS identifier 206, kernel build version 208, architecture 210 and configuration hash 212. These categories of configuration information 204 as shown in table 200 of FIG. 2 are merely examples, and table 200 may include additional columns corresponding to the various categories of endpoint information 140 as described herein above.

[0039] Binary identifiers 202 may be any type of identifier that corresponds to a particular binary maintained by cloud-based binary provider 104. For example, binary identifiers 202 may comprise a URI or other link to a resource, a hierarchical filesystem path, or any other identifier that allows binary provider 116 of cloud-based binary provider 104 to locate the binary corresponding to a particular binary identifiers 202 and provide the binary to endpoint 104. Moreover, binary identifiers 202 may include and/or reflect a binary version number for a binary.

[0040] OS identifier 206 may be any type of identifier that corresponds to a particular operating system distribution. For example, and as shown in FIG 2., OS identifier 206 may be Ubuntu or Fedora or indeed any other OS, in embodiments. Although depicted in FIG. 2 as simple text strings, other types of identifiers are possible in embodiments, and as will be understood by one of skill in the art.

[0041] Kernel build version 208 may correspond to, for example, an identifier of the Linux kernel installed on endpoint 104. Architecture 210 may correspond to the architecture on which endpoint 104 is running (e.g., x86_x64 vs ARM, etc.), and as described further herein above. Although not depicted in table 200 of FIG. 2, embodiments may maintain mappings between various binaries and some or all of the categories of endpoint information 140. Alternatively, however, embodiments may maintain mappings between the binaries maintained by cloud-based binary provider 104 and endpoint information 140 by generating a digest that uniquely represents endpoint information 140 for a particular endpoint 102. For example, configuration hash 212 as shown in table 200 of FIG. 2 is the MD5 hash of the concatenated values for each of OS identifier 206, kernel build version 208 and architecture 210 for a particular binary identifier 202. For example, configuration hash 212 that corresponds to the binary identifier 202 ‘Binary_l’ is the md5 hash of the string “Ubuntu 4.13 x86_x64”. Of course, other hash functions may be used, and the data hashed may comprise any suitable subset of data from endpoint information 140.

[0042] Alternatively, configuration hash 212 may comprise a “magic signature” comprising a hash of any number of or types of endpoint information 140, and indeed may be configurable. That is, configuration hash 212 need not correspond to one type of hash function that hashes together endpoint information 140 according to a rigid formula. In embodiments, configuration hash 212 may correspond to a magic signature version that itself may be stored as part of configuration information 204 of table 200 as shown in FIG. 2, wherein such signature version information dictates how a comparison hash may be constructed from the endpoint information 140 of an arbitrary endpoint.

[0043] With the benefit of the mappings illustrated in table 200 of FIG. 2, and as mentioned above, metadata obtainer 110 may determine if the requested or required binary is maintained by cloud-based binary provider 104 (e.g., is stored in data store 118 of cloud-based binary provider 104) by comparing endpoint configuration information included in endpoint information 140 to configuration information 204 corresponding to each binary maintained by cloud-based binary provider 104, and selecting a suitable match.

[0044] In the event the requested or required binary is not cached in data store 118, metadata obtainer 110 may cause compilation subsystem 112 to generate the requested or required binary by compiling such binary from corresponding source code. Compilation subsystem 112 may be configured to generate such binaries in various ways. For example, and as shown in FIG. 1, compilation subsystem 112 of cloud-based binary provider 104 may include a plurality of compilation units 120-1 through 120-n. In an embodiment, compilation units 120-1 through 120-n each correspond to a different operating system distribution, kernel version and computer architecture. For example, compilation unit 120-1 may comprise a server with x86_x64 architecture that is running the latest versions of the Ubuntu distribution and Uinux kernel. Where endpoint information 140 indicates that endpoint 102 is also running on the latest versions of the Ubuntu distribution and Linux kernel, compilation subsystem 112 will select compilation unit 120-1 for generating the requested or required binary as indicated by metadata obtainer 110. Other compilation units 120-2 through 120-n may be configured as instances of other operating system distributions (e.g., openSUSE) to support binary generation for endpoints that are running the same distribution. Furthermore, compilation unites 120-2 through 120-n may be configured to enable cross-compilation against multiple kernel version (e.g., by having and using the necessary and appropriate kernel headers for the target kernel version), or by performing compilation in a container, virtual machine or jail, where possible.

[0045] In an embodiment, after determining which of compilation units 120-1 through 120-n should generate the requested or required binary, compilation subsystem 112 may retrieve (or cause the selected compilation unit to retrieve) the source code corresponding to the requested or required binary from data store 118. The selected compilation unit of compilation subsystem 112 thereafter compiles the binary in accordance with the endpoint information, and thereafter stores the resulting binary in data store 118, while also providing the binary (i.e., kernel module or other binary 150 as depicted in FIG. 1) to binary provider 116 for forwarding to custom package manager 108 on endpoint 102.

[0046] Having received a compiled binary, whether a binary retrieved from data store 118, or one having been generated and provided by compilation subsystem 112, binary provider 116 is configured to thereafter send kernel module or other binary 150 to custom package manager 108 of endpoint 102, which subsequently installs the binary on endpoint 102.

[0047] In accordance with an embodiment, compilation subsystem 112 also includes signing unit 114. In certain instances, the operating system installed on an endpoint (e.g., endpoint 102) or certain organization policies may require that certain binaries be digitally signed before such binaries are installed or loaded on endpoint 102. In an embodiment, metadata obtainer 110 is further configured to determine, based at least on endpoint information 140, whether the requested or required binaries are to be signed. For example, one or more of metadata obtainer 110, compilation subsystem 112, signing unit 114 or binary provider 116 may be configured to determine whether a binary to be provided to endpoint 102 is to be signed, in embodiments. In such an instance, the newly- built binary generated by a compilation unit of compilation subsystem 112 or the binary retrieved from data store 118, may be provided to signing unit 114 for signing. Signing unit 114 may first determine whether the provided binary is already signed and if not, digitally sign the binary and provide the signed binary to binary provider 116 for forwarding to endpoint 102 as described above. Likewise, the signed version of the binary may likewise be subsequently stored in data store 118. In an embodiment, binary provider 116 may thereafter provide the signed binary to custom package manager 108 on endpoint 102 for installation thereon. Alternatively, binary provider 116 may package the signed binary into an installer and provide the installer to custom package manager 108 on endpoint 102, where such installer may install the binary on endpoint 102.

[0048] Whether binary provider 116 provides the signed binary directly to custom package manager 108 on endpoint 102, or instead packages the signed binary into an installer that is subsequently provided to custom package manager 108 on endpoint 102, binary provider 116 is likewise configured to deploy any necessary public key to endpoint 102 such that endpoint 102 may verify the signature of the signed binary. For example, such a public key may comprise a Certificate Authority signed certificate (i.e., a public key signed by a Certificate Authority such as Verigisn), a self-signed certificate, or a certificate signed by a private Certificate Authority.

[0049] Cloud-based binary provider 104 may be further configured to periodically check for new kernel versions automatically and ensure that developer provided source code or binary 125 continues to be operable on the new kernel version after rebuilding the binary corresponding to the developer code. In the event a build fails with the new kernel version, embodiments of cloud-based binary provider 104 may notify the corresponding developer (via, e.g., developer endpoint 106) of the breaking build. As described above, custom package manager 108 may be configured to periodically poll cloud-based binary provider 104 for kernel and/or application upgrades and will automatically request that cloud-based binary provider 104 recompile any required updated kernel modules in an event of a new kernel.

[0050] Further operational aspects of remote compilation system 100 of FIG. 1 will now be described in conjunction with FIG. 3 which depicts flowchart 300 of a method of providing a compiled binary from a remote compilation system, according to an example embodiment. In an embodiment, flowchart 300 may be performed by remote compilation system 100 of FIG. 1. Accordingly, flowchart 300 will be described with continued reference to system 100 of FIG. 1. However, the method of FIG. 3 is not limited to that implementation. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart 300 of FIG. 3 and system 100 of FIG. 1.

[0051] Flowchart 300 is an example method of providing a compiled binary from a remote compilation system, according to an embodiment. Note that flowchart 300 may be triggered to provide a compiled binary in various ways. For example, providing a binary may be triggered in response to a request from an endpoint (e.g., endpoint 102 as depicted in FIG. 1) to be provided with any available updated binaries. Alternatively, providing a binary may be triggered in response to a request that expressly identifies one or binaries to be provided.

[0052] Flowchart 300 begins at step 302. At step 302, a request for a compiled binary from an endpoint is received, the request including endpoint configuration information. For example, and with reference to remote compilation system 100 of FIG. 1, metadata obtainer 110 may be configured to receive a request including endpoint information 140 in the manner described above regarding remote compilation system 100. Alternatively, and also as described above, a front-end server (not shown in FIG. 1) of cloud-based binary provider 104 may receive the request, and thereafter forward endpoint information 140 to metadata obtainer 110, in an embodiment.

[0053] In accordance with one or more embodiments, the endpoint information (e.g., endpoint information 140) comprises at least one of kernel headers of a kernel installed on the endpoint, a kernel build version of a kernel installed on the endpoint, an identifier of an operating system distribution installed on the endpoint, an identifier of an operating system version installed on the endpoint, an identifier of one or more applications installed on the endpoint, an identifier of a computing architecture utilized by the endpoint, a listing of hardware devices utilized by the endpoint, or a compiler version utilized to compile at least one of the operating system distribution installed on the endpoint, the kernel installed on the endpoint or the one or more applications installed on the endpoint.

[0054] Flowchart 300 of FIG. 3 continues at step 304. In step 304, in response to receiving the request, it is determined whether the compiled binary requested by the endpoint is maintained by the binary providing system. For example, and with continued reference to remote compilation system 100 of FIG. 1, metadata obtainer 110 may be configured to determine if a copy of the requested binary (that is compatible with endpoint 102) is maintained by data store 118 of cloud-based binary provider 104 as described in further detail herein above.

[0055] In accordance with one or more embodiments, determining whether the compiled binary corresponding to the endpoint is maintained by the binary provider system is based on the endpoint configuration information. For example, with continued reference to remote compilation system 100 of FIG. 1, metadata obtainer 110 may determine whether the compiled binary is maintained by data store 118 of cloud-based binary provider 104 based on the endpoint information 140, compatibility may be determined based in part on endpoint information 140 included with the request.

[0056] Flowchart 300 of FIG. 3 continues at step 306. At step 306, based on a determination that the compiled binary is maintained by the binary provider system, a copy of the compiled binary is provided to the endpoint. For example, and with continued reference to remote compilation system 100 of FIG. 1, metadata obtainer 110 may be configured to cause binary provider 116 to retrieve a copy of the compiled binary from data store 118, and thereafter transmit the compiled binary (e.g., binary 150) to endpoint 102 in the manner described herein above. Alternatively, metadata obtainer 110 may retrieve the required binary from data store 118 and thereafter forward the binary to binary provider 116 for subsequent provision to endpoint 102. Flowchart 300 of FIG. 3 continues at step 308.

[0057] In step 308, based on a determination that the compiled binary is not maintained by the binary provider system, the compiled binary is generated based in part on the endpoint configuration information, and a copy of the generated compiled binary is provided to the endpoint. For example, and with continued reference to remote compilation system 100 of FIG. 1, metadata obtainer 110 may cause compilation subsystem 112 to generate the requested binary by compiling the binary based at least in part on endpoint information 140, and thereafter providing a copy of the compiled binary to endpoint 102 in the manner described generally above with respect to step 306. In an embodiment, and as described above, the binary may be generated based in part on software code (e.g., source code 124) provided to cloud-based binary provider 104 by a developer (e.g., from developer endpoint 106).

[0058] In accordance with one or more embodiments, the compiled binary corresponds to a software update for the endpoint. In accordance with one or more embodiments, software code from a developer is received from a developer endpoint. For example, with continued reference to FIG. 1, source code 124 from developer endpoint 106 is received by cloud-based binary provider 104. In accordance with one or more embodiments, the received software code comprises at least one of source code (e.g., source code 124), object code, symbolic assembly code, byte code, or compiled binary code.

[0059] In accordance with one or more embodiments, generating the compiled binary is further based on the received software code. For example, with continued reference to FIG. 1, compilation subsystem 112 may generate the compiled binary based on received source code 124. In another example, developer endpoint 106 compiles source code 124 into a binary 126 and provides binary 126 to cloud-based binary provider 104.

[0060] In the foregoing discussion of steps 302-308 of flowchart 300, it should be understood that at times, such steps may be performed in a different order or even contemporaneously with other steps. Other operational embodiments will be apparent to persons skilled in the relevant art(s). Note also that the foregoing general description of the operation of remote compilation system 100 of FIG. 1 is provided for illustration only, and embodiments of remote compilation system 100 may comprise different hardware and/or software, and may operate in manners different than described above. Indeed, steps of flowchart 300 may be performed in various ways.

[0061] For example, FIG. 4 depicts a flowchart 400 for providing a signed, compiled binary from a remote compilation system, according to an example embodiment. In an embodiment, flowchart 400 may be performed by remote compilation system 100 of FIG. 1. Accordingly, flowchart 400 of FIG. 4 will also be described with continued reference to remote compilation system 100 of FIG. 1. However, the method of FIG. 4 is not limited to that implementation. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart 400 and system 100 of FIG. 1.

[0062] Flowchart 400 begins at step 402. At step 402, it is determined whether the copy of the compiled binary is to be signed based on the endpoint configuration information. For example, and with reference to remote compilation system 100 of FIG. 1, signing unit 114 may determine whether the binary is to be signed based on endpoint information 140 that includes or reflects a requirement of the operating system installed on endpoint 102, a policy that requires binaries to be signed, or a signing requirement made expressly as part of the request that includes endpoint information 140. If a determination is made that the copy of the compiled binary is to be signed, flow continues to step 404. Otherwise, flow continues to step 410.

[0063] In step 404, it is determined whether the compiled binary is already signed. For example, with reference to FIG. 1, signing unit 114 of cloud-based binary provider 104 may be configured to determine whether the binary retrieved from data store 118 or generated by compilation subsystem 112 (as described above with respect to steps 306 and 308, respectively) is already signed, and as described in further detail above. In a determination is made that the compiled binary is unsigned, flow continues to step 406. Otherwise flow continues to step 408.

[0064] At step 406, based on a determination that the copy of the compiled binary is to be signed, and further based on a determination that the copy of the compiled binary is unsigned, the copy of the compiled binary is signed. For example, and with continued reference to remote compilation system 100 of FIG. 1, having determined that the compiled binary is not signed (e.g., because it is newly generated or the cached copy was not signed), and having determined at step 404 above that, based on endpoint information 140, the compiled binary should be signed, signing unit 114 may thereafter sign the compiled binary. Flowchart 400 of FIG. 4 continues at step 408.

[0065] In step 408, the copy of the signed, compiled binary is provided to the endpoint. For example, and with continued reference to remote compilation system 100 of FIG. 1, signing unit 114 may provide the signed, compiled binary to binary provider 116 that subsequently forwards the signed, compiled binary to custom package manager 108 of endpoint 102. Alternatively, the signed, compiled binary may be packaged by binary provider 116 into an installer that is subsequently provided to custom package manager 108 of endpoint 102.

[0066] In step 410, based on a determination that the copy of the compiled binary is to be unsigned, providing the copy of the compiled binary, unsigned, to the endpoint. For example, with continued reference to FIG. 1, signing unit 114 is not utilized to sign the copy of the compiled binary, and binary provider 116 provides the unsigned, compiled binary to endpoint 102.

[0067] In the foregoing discussion of steps 402-408 of flowchart 400 it should be understood that at times, such steps may be performed in a different order or even contemporaneously with other steps. For example, steps 402 and 404 need not be performed in that order, and instead step 404 may be performed before step 402, in embodiments. Other operational embodiments will be apparent to persons skilled in the relevant art(s). Note also that the foregoing general description of the operation of remote compilation system 100 of FIG. 1 is provided for illustration only, and embodiments of remote compilation system 100 may comprise different hardware and/or software, and may operate in manners different than described above.

III. Further Example Embodiments

[0068] A method implemented by a binary provider system is provided herein. The method comprising: receiving a request for a compiled binary from an endpoint, the request including endpoint configuration information; in response to receiving the request, determining whether the compiled binary requested by the endpoint is maintained by the binary provider system; based on a determination that the compiled binary is maintained by the binary provider system, providing a copy of the compiled binary to the endpoint; based on a determination that the compiled binary is not maintained by the binary provider system: generating the compiled binary based in part on the endpoint configuration information; and providing a copy of the generated compiled binary to the endpoint.

[0069] In an embodiment of the foregoing method, the method further comprises receiving software code from a developer endpoint.

[0070] In another embodiment of the foregoing method, the compiled binary corresponds to a software update for the endpoint.

[0071] In an embodiment of the foregoing method, said determining whether the compiled binary corresponding to the endpoint is maintained by the binary provider system is based on the endpoint configuration information.

[0072] In another embodiment of the foregoing method, providing the copy of the compiled binary to the endpoint comprises: determining, based on the endpoint configuration information, whether the copy of the compiled binary is to be signed; determining whether the copy of the compiled binary is already signed; based on a determination that the copy of the compiled binary is to be signed, and further based on a determination that the copy of the compiled binary is unsigned, signing the copy of the compiled binary; based on a determination that the copy of the compiled binary is already signed or based on said signing the copy of the compiled binary, providing the copy of the signed, compiled binary to the endpoint; and based on a determination that the copy of the compiled binary is to be unsigned, providing the copy of the compiled binary, unsigned, to the endpoint. [0073] In an embodiment of the foregoing method, the received software code comprises at least one of: source code; object code; symbolic assembly code; byte code; or compiled binary code.

[0074] In an embodiment of the foregoing method, generating the compiled binary is further based on the received software code.

[0075] In an embodiment of the foregoing method, the endpoint configuration information comprises at least one of: kernel headers of a kernel installed on the endpoint; a kernel build version of a kernel installed on the endpoint; an identifier of an operating system distribution installed on the endpoint; an identifier of an operating system version installed on the endpoint; an identifier of one or more applications installed on the endpoint; an identifier of a computing architecture utilized by the endpoint; a listing of hardware devices utilized by the endpoint; or a compiler version utilized to compile at least one of the operating system distribution installed on the endpoint, the kernel installed on the endpoint or the one or more applications installed on the endpoint.

[0076] A binary provider system is provided herein. The binary provider system comprises: one or more processors; and one or more memory devices coupled to the one or more processors, the one or more memory devices storing computer program logic for execution by the one or more processors, the computer program logic configured to: receive a request for a compiled binary from an endpoint, the request including endpoint configuration information; in response to receiving the request, determine whether the compiled binary requested by the endpoint is maintained by the binary provider system; based on a determination that the compiled binary is maintained by the binary provider system, provide a copy of the compiled binary to the endpoint; based on a determination that the compiled binary is not maintained by the binary provider system: generate the compiled binary based in part on the endpoint configuration information; and provide a copy of the generated compiled binary to the endpoint.

[0077] In an embodiment of the foregoing binary provider system, the computer program logic is further configured to receive software code from a developer endpoint.

[0078] In an embodiment of the foregoing binary provider system, the compiled binary corresponds to a software update for the endpoint. [0079] In an embodiment of the foregoing binary provider system, the computer program logic is further configured to determine whether the compiled binary corresponding to the endpoint is maintained by the binary provider system is based on the endpoint configuration information.

[0080] In an embodiment of the foregoing binary provider system, the computer program logic is further configured to provide the copy of the compiled binary to the endpoint by: determining, based on the endpoint configuration information, whether the copy of the compiled binary is to be signed; determining whether the copy of the compiled binary is already signed; based on a determination that the copy of the compiled binary is to be signed, and further based on a determination that the copy of the compiled binary is unsigned, signing the copy of the compiled binary; based on a determination that the copy of the compiled binary is already signed or based on said signing the copy of the compiled binary, providing the copy of the signed, compiled binary to the endpoint; and based on a determination that the copy of the compiled binary is to be unsigned, providing the copy of the compiled binary, unsigned, to the endpoint.

[0081] In an embodiment of the foregoing binary provider system, the received software code comprises at least one of: source code; object code; symbolic assembly code; byte code; or compiled binary code.

[0082] In an embodiment of the foregoing binary provider system, the computer program logic is further configured to generate the compiled binary further based on the received software code.

[0083] In an embodiment of the foregoing binary provider system, the endpoint configuration information comprises at least one of: kernel headers of a kernel installed on the endpoint; a kernel build version of a kernel installed on the endpoint; an identifier of an operating system distribution installed on the endpoint; an identifier of an operating system version installed on the endpoint; an identifier of one or more applications installed on the endpoint; an identifier of a computing architecture utilized by the endpoint; a listing of hardware devices utilized by the endpoint; or a compiler version utilized to compile at least one of the operating system distribution installed on the endpoint, the kernel installed on the endpoint or the one or more applications installed on the endpoint. [0084] A computer-readable storage medium having program instructions recorded thereon that, when executed by at least one processor, perform a method is provided herein. The method comprises: receiving a request for a compiled binary from an endpoint, the request including endpoint configuration information; in response to receiving the request, determining whether the compiled binary requested by the endpoint is maintained by the binary provider system; based on a determination that the compiled binary is maintained by the binary provider system, providing a copy of the compiled binary to the endpoint; based on a determination that the compiled binary is not maintained by the binary provider system: generating the compiled binary based in part on the endpoint configuration information; and providing a copy of the generated compiled binary to the endpoint.

[0085] In an embodiment of the foregoing computer-readable storage medium, the method further comprises receiving software code from a developer endpoint.

[0086] In an embodiment of the foregoing computer-readable storage medium, generating the compiled binary is further based on the received software code.

[0087] In an embodiment of the foregoing computer-readable storage medium, the received software code comprises at least one of: source code; object code symbolic; assembly code; byte code; or compiled binary code.

IV. Example Computer System Implementation

[0088] Custom package manager 108, cloud-based binary provider 104, metadata obtainer 110, compilation subsystem 112, compilation units 120-1 to 120-n, signing unit 114, binary provider 116, repositor(ies) 122, and/or data store 118 of FIG. 1 and/or the components included therein, table 200 of FIG. 2, and/or flowcharts 300 and/or 400, may be implemented in hardware, or any combination of hardware with software and/or firmware. For example, custom package manager 108, cloud-based binary provider 104, metadata obtainer 110, compilation unit 112, signer 114, binary provider 116, repositor(ies) 122, and/or data store 118 and/or the components included therein, table 200 of FIG. 2, and/or flowcharts 300 and/or 400, may be implemented as computer program code configured to be executed in one or more processors. In another example, custom package manager 108, cloud-based binary provider 104, metadata obtainer 110, compilation unit 112, signer 114, binary provider 116, repositor(ies) 122, and/or data store 118 and/or the components included therein, table 200 of FIG. 2, and/or flowcharts 300 and/or 400, may be implemented as hardware (e.g., hardware logic/electrical circuitry), or any combination of hardware with software (computer program code configured to be executed in one or more processors or processing devices) and/or firmware.

[0089] The embodiments described herein, including systems, methods/processes, and/or apparatuses, may be implemented using well known servers/computers, such as computer 500 shown in FIG. 5. For example, custom package manager 108, cloud-based binary provider 104, metadata obtainer 110, compilation unit 112, signer 114, binary provider 116, repositor(ies) 122, and/or data store 118 of FIG. 1 and/or the components included therein, table 200 of FIG. 2, and/or flowcharts 300 and/or 400, can each be implemented using one or more computers 500.

[0090] Computer 500 can be any commercially available and well known computer capable of performing the functions described herein, such as computers available from International Business Machines, Apple, Sun, HP, Dell, Cray, etc. Computer 500 may be any type of computer, including a desktop computer, a server, etc.

[0091] As shown in FIG. 5, computer 500 includes one or more processors (also called central processing units, or CPUs), such as a processor 506. Processor 506 is connected to a communication infrastructure 502, such as a communication bus. In some embodiments, processor 506 can simultaneously operate multiple computing threads.

[0092] Computer 500 also includes a primary or main memory 508, such as random access memory (RAM). Main memory 508 has stored therein control logic 524 (computer software), and data.

[0093] Computer 500 also includes one or more secondary storage devices 510. Secondary storage devices 510 include, for example, a hard disk drive 512 and/or a removable storage device or drive 514, as well as other types of storage devices, such as memory cards and memory sticks. For instance, computer 500 may include an industry standard interface, such a universal serial bus (USB) interface for interfacing with devices such as a memory stick. Removable storage drive 514 represents a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup, etc.

[0094] Removable storage drive 514 interacts with a removable storage unit 516. Removable storage unit 516 includes a computer useable or readable storage medium 518 having stored therein computer software 526 (control logic) and/or data. Removable storage unit 516 represents a floppy disk, magnetic tape, compact disc (CD), digital versatile disc (DVD), Blu-ray™ disc, optical storage disk, memory stick, memory card, or any other computer data storage device. Removable storage drive 514 reads from and/or writes to removable storage unit 516 in a well-known manner.

[0095] Computer 500 also includes input/output/display devices 504, such as monitors, keyboards, pointing devices, etc.

[0096] Computer 500 further includes a communication or network interface 520. Communication interface 520 enables computer 500 to communicate with remote devices. For example, communication interface 520 allows computer 500 to communicate over communication networks or mediums 522 (representing a form of a computer useable or readable medium), such as local area networks (LANs), wide area networks (WANs), the Internet, etc. Network interface 520 may interface with remote sites or networks via wired or wireless connections. Examples of communication interface 522 include but are not limited to a modem, a network interface card (e.g., an Ethernet card), a communication port, a Personal Computer Memory Card International Association (PCMCIA) card, etc.

[0097] Control logic 528 may be transmitted to and from computer 500 via the communication medium 522.

[0098] Any apparatus or manufacture comprising a computer useable or readable medium having control logic (software) stored therein is referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer 500, main memory 508, secondary storage devices 510, and removable storage unit 516. Such computer program products, having control logic stored therein that, when executed by one or more data processing devices, cause such data processing devices to operate as described herein, represent embodiments of the invention.

[0099] Devices in which embodiments may be implemented may include storage, such as storage drives, memory devices, and further types of computer-readable media. Examples of such computer-readable storage media include a hard disk, a removable magnetic disk, a removable optical disk, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and the like. As used herein, the terms "computer program medium" and "computer-readable medium" are used to generally refer to the hard disk associated with a hard disk drive, a removable magnetic disk, a removable optical disk (e.g., CDROMs, DVDs, etc.), zip disks, tapes, magnetic storage devices, MEMS (micro-electromechanical systems) storage, nanotechnology-based storage devices, as well as other media such as flash memory cards, digital video discs, RAM devices, ROM devices, and the like. Such computer-readable storage media may store program modules that include computer program logic for implementing custom package manager 108, cloud-based binary provider 104, metadata obtainer 110, compilation unit 112, signer 114, binary provider 116, repositor(ies) 122, and/or data store 118 of FIG. 1 and/or the components included therein, table 200 of FIG. 2, and/or flowcharts 300 and/or 400, and/or further embodiments described herein. Embodiments of the invention are directed to computer program products comprising such logic (e.g., in the form of program code, instructions, or software) stored on any computer useable medium. Such program code, when executed in one or more processors, causes a device to operate as described herein.

[0100] Note that such computer-readable storage media are distinguished from and nonoverlapping with communication media. Communication media embodies computer- readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wireless media such as acoustic, RF, infrared and other wireless media, as well as wired media. Example embodiments are also directed to such communication media.

[0101] It is noted that while FIG. 5 shows a server/computer, persons skilled in the relevant art(s) would understand that embodiments/features described herein could also be implemented using other well-known processor-based computing devices, including but not limited to, smart phones, tablet computers, netbooks, gaming consoles, personal media players, and the like.

V. Conclusion

[0102] While various embodiments of the disclosed subject matter have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those skilled in the relevant art(s) that various changes in form and details may be made therein without departing from the spirit and scope of the embodiments as defined in the appended claims. Accordingly, the breadth and scope of the disclosed subject matter should not be limited by any of the abovedescribed exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

28 WHAT IS CLAIMED IS:

1. A method implemented by a binary provider system, comprising: receiving a request for a compiled binary from an endpoint, the request including endpoint configuration information; in response to receiving the request, determining whether the compiled binary requested by the endpoint is maintained by the binary provider system; based on a determination that the compiled binary is maintained by the binary provider system, providing a copy of the compiled binary to the endpoint; based on a determination that the compiled binary is not maintained by the binary provider system: obtaining the compiled binary based in part on the endpoint configuration information; and providing a copy of the generated compiled binary to the endpoint.

2. The method of claim 1, further comprising receiving software code from a developer endpoint.

3. The method of claim 1, wherein obtaining the compiled binary based in part on the endpoint configuration information comprises, receiving the compiled binary from a developer endpoint, the compiled binary being generated based in part on the endpoint configuration information.

4. The method of claim 1, wherein said determining whether the compiled binary corresponding to the endpoint is maintained by the binary provider system is based on the endpoint configuration information.

5. The method of claim 1, wherein providing the copy of the compiled binary to the endpoint comprises: determining, based on the endpoint configuration information, whether the copy of the compiled binary is to be signed; determining whether the copy of the compiled binary is already signed; based on a determination that the copy of the compiled binary is to be signed, and further based on a determination that the copy of the compiled binary is unsigned, signing the copy of the compiled binary; based on a determination that the copy of the compiled binary is already signed or based on said signing the copy of the compiled binary, providing the copy of the signed, compiled binary to the endpoint; and based on a determination that the copy of the compiled binary is to be unsigned, providing the copy of the compiled binary, unsigned, to the endpoint.

6. The method of claim 2, wherein the received software code comprises at least one of: source code; object code; symbolic assembly code; byte code; or compiled binary code.

7. The method of claim 2, wherein obtaining the compiled binary is further based on the received software code.

8. The method of claim 1, wherein the endpoint configuration information comprises at least one of: kernel headers of a kernel installed on the endpoint; a kernel build version of a kernel installed on the endpoint; an identifier of an operating system distribution installed on the endpoint; an identifier of an operating system version installed on the endpoint; an identifier of one or more applications installed on the endpoint; an identifier of a computing architecture utilized by the endpoint; a listing of hardware devices utilized by the endpoint; or a compiler version utilized to compile at least one of the operating system distribution installed on the endpoint, the kernel installed on the endpoint or the one or more applications installed on the endpoint.

9. A binary provider system, comprising: one or more processors; and one or more memory devices coupled to the one or more processors, the one or more memory devices storing computer program logic for execution by the one or more processors, the computer program logic configured to: receive a request for a compiled binary from an endpoint, the request including endpoint configuration information; in response to receiving the request, determine whether the compiled binary requested by the endpoint is maintained by the binary provider system; based on a determination that the compiled binary is maintained by the binary provider system, provide a copy of the compiled binary to the endpoint; based on a determination that the compiled binary is not maintained by the binary provider system: obtain the compiled binary based in part on the endpoint configuration information; and provide a copy of the generated compiled binary to the endpoint.

10. The binary provider system of claim 9, wherein the computer program logic is further configured to receive software code from a developer endpoint.

11. The binary provider system of claim 9, wherein the computer program logic is further configured to obtain the compiled binary based in part on the endpoint configuration information comprises by receiving the compiled binary from a developer endpoint, the compiled binary being generated based in part on the endpoint configuration information.

12. The binary provider system of claim 9, wherein the computer program logic is further configured to determine whether the compiled binary corresponding to the endpoint is maintained by the binary provider system is based on the endpoint configuration information.

13. The binary provider system of claim 9, wherein the computer program logic is further configured to provide the copy of the compiled binary to the endpoint by: determining, based on the endpoint configuration information, whether the copy of the compiled binary is to be signed; determining whether the copy of the compiled binary is already signed; based on a determination that the copy of the compiled binary is to be signed, and further based on a determination that the copy of the compiled binary is unsigned, signing the copy of the compiled binary; based on a determination that the copy of the compiled binary is already signed or based on said signing the copy of the compiled binary, providing the copy of the signed, compiled binary to the endpoint; and based on a determination that the copy of the compiled binary is to be unsigned, providing the copy of the compiled binary, unsigned, to the endpoint.

14. The binary provider system of claim 10, wherein the received software code comprises at least one of: source code; object code; symbolic assembly code; byte code; or compiled binary code.

15. The binary provider system of claim 10, wherein the computer program logic is further configured to obtain the compiled binary further based on the received software code.

16. The binary provider system of claim 9, wherein the endpoint configuration information comprises at least one of: kernel headers of a kernel installed on the endpoint; a kernel build version of a kernel installed on the endpoint; an identifier of an operating system distribution installed on the endpoint; an identifier of an operating system version installed on the endpoint; 32 an identifier of one or more applications installed on the endpoint; an identifier of a computing architecture utilized by the endpoint; a listing of hardware devices utilized by the endpoint; or a compiler version utilized to compile at least one of the operating system distribution installed on the endpoint, the kernel installed on the endpoint or the one or more applications installed on the endpoint.

17. A computer-readable storage medium having program instructions recorded thereon that, when executed by at least one processor, perform a method, the method comprising: receiving a request for a compiled binary from an endpoint, the request including endpoint configuration information; in response to receiving the request, determining whether the compiled binary requested by the endpoint is maintained by the binary provider system; based on a determination that the compiled binary is maintained by the binary provider system, providing a copy of the compiled binary to the endpoint; based on a determination that the compiled binary is not maintained by the binary provider system: obtaining the compiled binary based in part on the endpoint configuration information; and providing a copy of the generated compiled binary to the endpoint.

18. The computer-readable storage medium of claim 17, wherein the method further comprises: receiving software code from a developer endpoint; and obtaining the compiled binary based in part on the endpoint configuration information is based on the received software code.

19. The computer-readable storage medium of claim 17, wherein obtaining the compiled binary based in part on the endpoint configuration information comprises, receiving the compiled binary from a developer endpoint, the compiled binary being generated based in part on the endpoint configuration information. 33

20. The computer-readable storage medium of claim 18, wherein the received software code comprises at least one of: source code; object code; symbolic assembly code; byte code; or compiled binary code.