summaryrefslogtreecommitdiffstats
path: root/recipes-security/refpolicy/refpolicy_git.inc
Commit message (Collapse)AuthorAgeFilesLines
* refpolicy: update to 2.20190201 and git HEAD policiesJoe MacDonald2019-04-121-52/+3
| | | | | | | Additionally, the README has fallen out of date, update it to reflect the current reality of layer dependencies. Signed-off-by: Joe MacDonald <joe@deserted.net>
* refpolicy: fix up all refpolicy 20170224 builds for current masterJoe MacDonald2018-10-301-2/+0
| | | | Signed-off-by: Joe MacDonald <joe@deserted.net>
* refpolicy_git.inc: lock SRCREVs on the actual version hashesAwais Belal2018-10-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Using AUTOREV in the main repository has its downsides. 1. The checked out version isn't actually the version depicted by PV. 2. Breaks builds in scenarios where network isn't available or BB_NO_NETWORK is used even after sources are already fetched. 1 is self explanatory, for 2 whenever SRCREV is set to AUTOREV and SRCPV is used in PV the fetcher tries to access the network in order to determine SRCPV (bb.fetch2.get_srcrev) and fails for obvious reasons during parsing even when versioned recipes are used as PREFERRED_VERSION because parsing still happens for recipes that are in BB's search paths and we see. Traceback (most recent call last): bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception NetworkAccess: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command git -c core.fsyncobjectfiles=0 ls-remote git://github.com/TresysTechnology/refpolicy.git (for url git://github.com/TresysTechnology/refpolicy.git) So we lock the REVs and do that with a soft assignment which allows overriding the REVs from elsewhere. Signed-off-by: Awais Belal <awais_belal@mentor.com> Signed-off-by: Joe MacDonald <joe@deserted.net>
* refpolicy: Add '/bin/bash.bash', an update-alternative to the policyMark Hatle2017-09-141-0/+1
| | | | Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
* refpolicy-git: Update to lastest git versionMark Hatle2017-09-141-0/+2
| | | | Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
* refpolicy-git: clean up fallout from stable uprevJoe MacDonald2017-05-041-2/+0
| | | | Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
* refpolicy: update git recipesJoe MacDonald2017-05-031-1/+0
| | | | | | | | | The targeted, mls and minimum recipes had fallen far behind the upstream refpolicy repository. Refresh all patches and discard ones that are obviously no longer needed. This should not have any functional change on the policies. Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
* refpolicy-git: Update patchesJoe MacDonald2017-01-061-3/+0
| | | | | | | A number of upstream changes caused patch conflicts or duplication in the final policy. Update the list of git patches appropriately. Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
* refpolicy: SRCREV_FORMAT neededJoe Slater2015-10-221-0/+1
| | | | | Signed-off-by: Joe Slater <jslater@windriver.com> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
* refpolicy git: update refpolicy to git repositoryShrikant Bobade2015-08-071-0/+62
A straight update from refpolicy 2.20140311 to refpolicy git repository for the core policy variants and forward-porting of policy patches as appropriate. This approach is useful for building refpolicy & refpolicy-contrib directly from the git repos, rather than release tarballs. It helps to check the refpolicy based on source commits by just updating the git repo rev. as appropriate in refpolicy_git.inc ref: https://github.com/TresysTechnology/refpolicy/wiki Signed-off-by: Shrikant Bobade <shrikant_bobade@mentor.com> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-08-06 11:01:50 +0000