Header section download of package

A header section of a package may be downloaded from a server. The header section may be analyzed to determine if a data section of the package is secure and a correct version. The data section of the package is downloaded, if the data section is secure and the correct version. The package is a single file.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a U.S. National Stage Application of and claims priority to International Patent Application No. PCT/US2013/058064, filed on Sep. 4, 2013, and entitled “HEADER SECTION DOWNLOAD OF PACKAGE,” which is hereby incorporated by reference in its entirety.

BACKGROUND

A device may require a remote update, such as an update to software or firmware. A server may provide an executable package to the device in order to carry out the update. Different types of devices may require different types of updates at different times. Manufacturers, vendors and/or suppliers are challenged to provide users of the devices with more efficient and secure methods for providing updates.

DETAILED DESCRIPTION

Specific details are given in the following description to provide an understanding of examples of the present techniques. However, it will be understood that examples of the present techniques may be practiced without these specific details. For example, systems may be shown in block diagrams in order not to obscure examples of the present techniques in unnecessary detail. In other instances, well-known processes, structures and techniques may be shown without unnecessary detail in order to avoid obscuring the examples of the present techniques.

A client may initially be given an image for a device. Subsequently, the client may need to be given updates remotely for the device. Current options for providing the updates may be through package formats such as .deb, .rpm and .tar.gz. However, these formats may not allow for remote type checking via HTTP or FTP because a header section (which includes information about the package) and a data section of a package are bundled without a clear separation point. Thus, the client may have issues downloading the correct version of the package. Further, these formats may not have any inherent way to check for authenticity, thus raising security issues. While the package may be signed in some cases, a separate signature file must be present along with the package, making it difficult for support staff to maintain and distribute.

Further, packages of these formats may not be inherently scriptable because after data of the package is unpacked, only a predetermined set of functions may be run on the data to install it. Also, while this type of package may have a separate XML file associated with it that gives a description of the package, the XML file itself cannot be authenticated. Thus, these formats do not allow for remote type-checking via a single file or for a secure download. While other update solutions, such as web based solutions (like apt, windows update, android firmware) may provide remote type-checking, the update cannot occur via a single file.

Examples may provide a secure packaging format contained within a single file with a defined separation point between variable length header and data sections. An example device may include a download unit, a validation unit and an authentication unit. The download unit may download a header section of a package. The validation unit may analyze package information extracted from the header section. The package information may include information about a data section of the package. The authentication unit may analyze a certificate extracted from the header section. The certificate may verify a source of the data section. The download unit may download the data section of the package, if the package information is validated and the certificate is authenticated. The package is contained within a single file.

Hence, examples of present techniques may provide a new packaging format that contains a parsable XML header section, which can be downloaded and checked independently of the data section. That data section may contain multiple sub packages (such as .deb, tar.gz, .rpm, or individual files) that can be unpacked in an arbitrary, scriptable fashion. Examples of the package may be capable of having an SSL signed data section to prove authenticity, and be created in the field or on site. By being contained in a single file, examples of the package may allow for simplified distribution and sharing amongst distribution partners, customers and support staff.

Referring now to the drawings,FIG. 1is an example block diagram of a device100to download a header section152of a package150. The device100may couple to or be included in any type of computing device to receive remote updates, such as a notebook computer, a desktop computer, an all-in-one system, a server, a network device, a wireless device, a storage device, a mobile device, a thin client, a retail point of sale device, a gaming device, a scientific instrument, and the like.

In the example ofFIG. 1, the device100includes a download unit110, an authentication unit120and a validation unit130. The download, authentication and validation units110,120and130may include, for example, a hardware device including electronic circuitry for implementing the functionality described below, such as control logic and/or memory. In addition or as an alternative, the download, authentication and validation units110,120and130may be implemented as a series of instructions encoded on a machine-readable storage medium and executable by a processor.

The download unit110may download a header section152of a package150. The package150is a single file containing a collection of data or information, such as the header section152and a data section158. The header section152may follow a clear and unambiguous specification or format, to allow for parsing, such as according to an Extensible Markup Language (XML) format.

The validation unit130may analyze package information154extracted from the header section152. The package information154may include information about a data section158of the package150, such as metadata, installation requirements or compatibility, and the like. Example package information154may include information about an operating system (OS) type, a hardware dependency for installation of the package a software dependency for installation of the package, a localized title, a version, a description of the data section158, release notes, and any other data that may identify whether the package150should be installed.

Thus, the validation unit130may validate the package information154if the package information154matches a specification of the device100. For example, the validation process may include ensuring that a type of OS listed in the package information154matches an OS installed on the device100, that a version of the package150listed in the package information154is greater than that of a package currently installed on the device100, that the data section158includes the desired data or software, and the like.

The authentication unit120may analyze a certificate156′ extracted from the header section152. The certificate156′ may verify a source of the data section158. For example, the package150may be downloaded by the device100according to the Secure Socket Layer (SSL) protocol. In this case, a server (not shown) providing the package150may include a signed certificate156′ in the header section152. The authentication unit120may check that the certificate156′ was issued by a trusted party, such as a trusted root Certification Authority (CA), that the certificate156′ is still valid and/or that the certificate156′ is related to a site contacted by the device100.

The download unit110may download the data section158of the package150, if the package information154is validated and the certificate is authenticated. Hence, the device100may be able to securely, such as via SSL, determine whether the data section158of the package150should be downloaded by first downloading the header section152of the package150. The header section152is parsable and downloadable independently of the data section158. Yet the header and data sections152and158are part of a single file or package150, thus reducing a likelihood that the header section152could be tampered with independently of the data section158.

FIG. 2is another example block diagram of a device200to download a header section152of a package250. The device200may couple to or be included in any type of computing device receive remote updates, such as a controller, a notebook computer, a desktop computer, an all-in-one system, a server, a network device, a wireless device, a storage device, a mobile device, a thin client, a retail point of sale device, a gaming device, a scientific instrument, and the like.

The device200ofFIG. 2may include at least the functionality and/or hardware of the device100ofFIG. 1. For example, the device200ofFIG. 2includes the download unit110. Further, the authentication and validation units220and230of the device200may include at least the functionality and/or hardware of the authentication and validation units120and130of the device100. The device200is further shown to include an install unit240and a database270.

The install unit240may include, for example, a hardware device including electronic circuitry for implementing the functionality described below, such as control logic and/or memory. In addition or as an alternative, the install unit240may be implemented as a series of instructions encoded on a machine-readable storage medium and executable by a processor. The database270may be any electronic, magnetic, optical, or other physical storage device that is able to store data persistently, such as a HDD, SDD and/or flash memory.

In addition, the device200interfaces with a server240. The server240may be any type of system or device that communicates across a network to provide, or help to provide, a network service. Example types of servers240may include a database server, file server, mail server, print server, web server, gaming server, application server, or some other kind of server.

The download unit110may determine a separation point between the header and data sections152and258based on a number sequence252included in the package250. The number sequence252may be any sequence or patter of numbers uniquely identifiable by the download unit110, such as a repeating sequence of “1010”. The download unit110may pause a download of the package250after the number sequence252is downloaded, as this will signal an end of the header section152. The download unit110may resume a download of the package250after the package information252is validated and the certificate156′ is authenticated, in order to download the data section258. As shown inFIG. 2the validation unit230may compare the package information154′ to the device specification232, in order to determine whether to validate the package information154′. The certificate156′ analyzed by the authentication unit220may be signed by the server240, such as via a pretty good privacy (pgp) signature.

The data section258is shown to include at least one data file262and a script260. Example data files262may include multiple sub packages such as .deb, tar.gz, .rpm and the like, or individual files. The data file(s)262may in any format. As the data file(s)262may all be managed and installed by the installation script260′, it may not be necessary to have any restrictions on file format. For instance, the data file262may span in range from a basic file to be unzipped to an OS to be rebooted or installed.

The install unit240may install the package250after the data section258is downloaded. The install unit240may run the script260to install and/or unpack the data file262. The install unit240may decompress the data file262before the script260is run, such as to a temporary location like Random Access Memory (RAM) (not shown). The package250may itself, for example, be in the .xar format or any other format that allows for the capabilities described herein.

For example, the script260may include generic package installation functions to run common unpacking tasks such as unzip, tar, dpkg, rar etc., and/or the script260may be customized to the data file262using a programming language such as Bash, Perl, Java, Python, complied C code or even pre-compiled binary. The script260may be run with permission to at least one of read, modify and execute a data component (not shown) of the device200and execute system calls of the device200with administrator privileges. After the package250is installed, the install unit20may mark the package250as installed in the database270.

FIG. 3is an example block diagram of a computing device300including instructions for downloading a header section of a package. InFIG. 3, the computing device300includes a processor310and a machine-readable storage medium320. The machine-readable storage medium320further includes instructions322,324and326for downloading a header section of a package.

The computing device300may be, for example, a controller, a secure microprocessor, a notebook computer, a desktop computer, an all-in-one system, a server, a network device, a wireless device, or any other type of user device capable of executing the instructions322,324and326. In certain examples, the computing device300may include or be connected to additional components such as memories, sensors, displays, etc.

The processor310may be, at least one central processing unit (CPU), at least one semiconductor-based microprocessor, other hardware devices suitable for retrieval and execution of instructions stored in the machine-readable storage medium320, or combinations thereof. The processor310may fetch, decode, and execute instructions322,324and326to implement downloading the header section of the package. As an alternative or in addition to retrieving and executing instructions, the processor310may include at least one integrated circuit (IC), other control logic, other electronic circuits, or combinations thereof that include a number of electronic components for performing the functionality of instructions322,324and326.

The machine-readable storage medium320may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, the machine-readable storage medium320may be, for example, Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a Compact Disc Read Only Memory (CD-ROM), and the like. As such, the machine-readable storage medium320can be non-transitory. As described in detail below, machine-readable storage medium320may be encoded with a series of executable instructions for downloading the header section of the package.

Moreover, the instructions322,324and326when executed by a processor (e.g., via one processing element or multiple processing elements of the processor) can cause the processor to perform processes, such as, the process ofFIG. 4. For example, the download header instructions322may be executed by the processor310to download a header section of a package from a server (not shown). The analyze instructions324may be executed by the processor310to analyze the header section to determine if a data section of the package is secure and a correct version.

The download data instructions326may be executed by the processor310to download the data section of the package, if the data section is secure and the correct version. The package is a single file and so the header and data section may also be part of a single file. The downloaded data section may include a data file and a script. The data file may be installed according to the script. A database may be updated to mark the data file as installed.

FIG. 4is an example flowchart of a method400for downloading a header section of a package. Although execution of the method400is described below with reference to the device200, other suitable components for execution of the method400can be utilized, such as the device100. Additionally, the components for executing the method400may be spread among multiple devices (e.g., a processing device in communication with input and output devices). In certain scenarios, multiple devices acting in coordination can be considered a single device to perform the method400. The method400may be implemented in the form of executable instructions stored on a machine-readable storage medium, such as storage medium320, and/or in the form of electronic circuitry.

At block410, the device200downloads a header section152of a package250from a server240. The device200may receive a uniform resource locator (URL) from the server240to download the package250. Further, when downloading the header section152, the device200may pause downloading the package250after a number sequence252after an end of the header section152is downloaded.

Then, at block420, the device200extracts package information154′ and a certificate156′ from the header section152. Next, at block430, the device200validates the package information154′ to determine if the package250is compatible with the device200. At block440, the device200authenticates the certificate156′ to verify that the package250is from a trusted source. Lastly, the block450, the device200downloads a data section258of the package250, if the package information154′ is validated and the certificate156′ is authenticated.

The validating at block430may include displaying the package information154′ to a user of the device200, such as via a user interface like a monitor. The package information154′ may include a contents and/or installation requirements of the data section258. The downloading at block450may further resume downloading the package250if the user approves downloading the data section258after the package information154is displayed. For instance, the user may review the contents or installation requirements to ensure that the correct package250is being downloaded.